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1.0 INTRODUCTION 


1.1 Identification of Volume 

This is the Product Specification Documentation Standard and Data 
Item Descriptions Volume rolled-out from the Information System 
Life-Cycle and Documentation Standards. 


1.2 Scope of Volume 

A product specification contains all technical information for 
specifying and documenting an information system or a hardware, 
software, or operational procedures component. This volume 
states the SMAP documentation standard for a product 
specification document applicable to all NASA information systems 
and software, hardware, and operational procedures components and 
related processes. 

The selection, adaptation, and enforcement of these documentation 
standards is the responsibility of the cognizant program/project 
manager. 

IT IS ASSUMED WITHIN THIS VOLUME THAT THE READER OF THIS STANDARD 
IS FAMILIAR WITH THE TERMS AND CONTENTS OF THE PARENT VOLUME 
CONCERNING INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION 
STANDARDS . 


1.3 Purpose and Objectives of Volume 

The purpose of this volume is to provide a well organized, easily 
used standard for providing technical information needed for 
developing information systems and software, hardware, and 
operational procedures components and related processes. 


1.4 Volume Status and Schedule 

Release 4.2C was the first complete release for Version 4 of the 
Information System Life-Cycle and Documentation Standards 
document. All five volumes of the document underwent a SMAP and 
agency review. Release 4.3 is an update to Release 4.2C based on 
the approved RIDs from this review. The RID review board 
determined that change bars will not be used to show the 
differences between Releases 4.2C and 4.3, as 4.3 is the first 
baselined release of the Version 4 standards. 
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1.5 Volume Organization and Roll-Out 

Sections 1 and 2 of this volume identify it, describe its 
purpose, and cite other documents affecting it. Section 3 
provides the rationale and scope for this documentation 
standard. Section 4 presents the actual standard and related 
rules for product specification documentation and illustrates the 
roll-out concept. Section 5 offers guidelines for applying the 
standard to the needs of a particular application and 
organizational environment. Section 6 proposes means for 
assuring and enforcing the standard. 

The Data Item Descriptions (DIDs) for a product specification are 
contained in Section 7 of this volume. 

Section 8 contains a list of abbreviations and acronyms, and 
Section 9 a glossary. Section 10 is available for notes. 

Section 11 contains five appendices showing sample outlines for 
complete product specifications written as single volumes for an 
information system, a hardware component, a software component, 
and an operational procedures component, and also for the 
development of new standards. 
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2 . 0 RELATED DOCUMENTATION 


2 . 1 Parent Documents 

The following document is the parent of this volume: 

1) Information System Life-Cycle and Documentation Standards, 
Release 4.3, 2/28/89. Washington: NASA Office of Safety, 

Reliability, Maintainability, and Quality Assurance. 


2.2 Applicable Documents 

The following volumes/documents are referenced herein and are 

directly applicable to this document: 

1) Management Plan Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

2) Assurance Specification Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

3) Management Control and Status Reports Documentation Standard 

and Data Item Descriptions (DID) Volume of the Information 
System Life-Cycle and Documentation Standards, Release 4.3, 
2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

4) IEEE Standard Glossary of Software Engineering Terminology. 

ANSI/IEEE Std 729-1983. New York: Institute of Electrical 

and Electronic Engineers, Inc. 


2 . 3 Information Documents 

The following documents, although not directly applicable, are 
referenced for historical continuity: 

1) Military Standard for Defense System Software Development, 
DoD-STD-2 167 , 4 June 1985, and DoD-STD-2167A, 27 October 1987: 

2) NASA Software Data Item Descriptions, Version 3, November 

1986. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. (Additional Data 
Item Descriptions were published as Versions 3.1 - 3.5 in 
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1987.) 

3) Space Station Program Software Management Policies, November 
1986. 

4) Information Processing Resources Management, NHB 2410. ID, 
April 1985. 
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3.0 OVERVIEW OF THE PRODUCT SPECIFICATION DOCUMENTATION STANDARD 


3.1 Scope of Standard 

The SMAP Product Specification Documentation Standard is 
applicable to all NASA information systems and their software, 
hardware, and operational procedures components. 

The selection, adaptation, and enforcement of these documentation 
standards is the responsibility of the cognizant program/project 
manager. 

It is important to note that these documentation standards are 
not management, technical and engineering, or assurance 
standards. However, the life-cycle and documentation standards 
provide the mechanism to document the selected activities and 
related specifications supporting any management, technical and 
engineering, or assurance standards. 


3.2 Rationale for Standard 

The rationale for the documentation structure presented in this 
standard is to provide visibility and to allow management to 
assign responsibility for the generation of such documentation. 

As specified by the Information System Life-Cycle and 
Documentation Standards, the documentation set for each 
information system and component consists of: 

1) a management plan 

2) a product specification 

3) an assurance specification 

4) a management control and status reports document 

An assumption upon which the SMAP documentation standard is based 
is that it is the responsibility of program/project management to 
decide what information is to be formally recorded. The 
documentation standard merely indicates the organization for such 
information. 

The function of the product specification documentation standard 
is to provide a uniform and effective method for correlating, 
integrating, and presenting all technical and product information 
for an information system and software, hardware, and operational 
procedures components. 

Because the management plan may include the development of 
support products such as standards or a facility on which to 
conduct prototyping, the product specification and other 
documents in this standard may be used for the development of 
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products needed to support the development of an information 
system or component. 


3.3 Interface With Other Standards 

This documentation standard is derived from the NASA Version 3 
software standards maintained by NASA Headquarters Code Q, Office 
of Safety, Reliability, Maintainability and Quality Assurance. 

This documentation standards volume is one of four that augment 
and detail the life-cycle standards for information systems 
specified in the parent document. The other three documentation 
standards volumes are referenced in Section 2.2. 
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4.0 THE PRODUCT SPECIFICATION DOCUMENTATION STANDARD 

The product specification documentation standard describes the 
format and content of all technical product specifications at a 
single node in an information system's decomposition tree. (For 
more information on system decomposition, refer to the 
Information System Life-Cycle and Documentation Standards . ) 


4.1 Product Specification Structure 

The structure for a product specification is illustrated in 
Figure 4-1. The structures for information system and component 
product specifications are similar, differing only to the extent 
necessary to encompass the unique activities for an information 
system or component. 

The purpose of this structure is to relate individual elements of 
technical and product information to each other and to integrate 
them all into a coordinated whole. The structure also provides a 
mechanism for partitioning the product specification document 
into multiple volumes when necessary. 


CONCEPT 

REQUIREMENTS 

DESIGN 

VERSION DESCRIPTION 

USER AND OPERATOR DOCUMENTATION 

MAINTENANCE MANUAL 


Figure 4-1. Structure for Information System Product 

Specification 


4.2 Responsibility for Preparation of the Product Specification 

The product specification is prepared in accordance with the 
management plan for the information system or component. Every 
management plan reflects an agreement between the acquirer of an 
information system or component and the providers, including the 
development provider. 
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The acquirer's management, engineering, and assurance 
requirements are specified in the acquisition plan section of the 
management plan. The developer is responsible for preparing the 
development plan in response to these requirements. The product 
specification is then prepared as designated in the development 
plan section of the management plan. The acquirer may develop 
the requirements section of the product specification (or a draft 
thereof) as part of the procurement process. 

Each product specification document is prepared for a particular 
information system or component? i.e., for a node in the system 
decomposition tree. The physical organization (i.e., roll-out 
into separate volumes) and content for the product specification 
document is dependent upon the development effort specified m 
the management plan for that node. 

In addition, a product specification is prepared by the 
appropriate developer for any support product (such as new 
standards or a capability for prototyping) being developed. 

The product specification includes trades analyses as well as the 
requirements finally chosen for the information system or 
component, the design specifications, and the description of the 
final product. 


4.3 Roll-Out Concept and Template 

For a small information system or component, it is possible that 
each doc umen t of the documentation set (management plan, product 
specification, assurance specification, and management control 
and status reports document) can be written as a single physical 
volume. However, many information systems and components require 
that multiple volumes be used for each document. In the case 
where a documentation set document for an information system or 
component requires more than one volume, the concept of 
"roll-out" is employed. 

The roll-out concept provides a mechanism whereby sections of the 
document are packaged as separate volumes. The parent document 
or volume contains pointers to each of the rolled-out sections. 
The rolled-out volume contains a pointer back to its parent. 

This preserves the overall integrity of the documentation set 
structure while offering the convenience of separately preparing 
a section of the document. (For convenience of packaging and 
traceability to Version 3, the DIDs for this document are 
presented in rolled-out format.) The decision on which sections * 
of the document are rolled-out is stated in the management plan 
by the appropriate manager as identified in Section 4.2. 

The Product Specification DIDs for information systems (SMAP-DID- 
POOO-SY) , hardware (SMAP-DID-POOO-HW) , software (SMAP-DID-POOO- 
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SW) , and operational procedures (SMAP-DID-POOO-OP) are the top 
level DIDs for this document in the documentation set. 

The additional DIDs in Section 7 provide the details for the 
document content. Each DID consists of: 1) a table of contents 

and 2) content description. 

A separate DID is provided to describe the content of the Product 
Specification Template DID (SMAP-DID-P999) itself. The standard 
template (Figure 4-2) is used as part of the roll-out mechanism. 

Because the rolled-out volume represents a single section in its 
parent document or volume, sections 3.0 through N.O of the 
rolled-out volume are actually the major subheadings for the 
section in the parent document or volume. 

The Abbreviations and Acronyms section defines all acronyms and 
abbreviations used within the document or volume. The Glossary 
section includes definitions of special terms used within the 
document or volume. 

The Notes section is used for supplemental information that is 
not part of the formal, binding information presented elsewhere 
in the document or volume. 

Appendices are considered to be an integral part of the document 
or volume. They may be separately page numbered, or included in 
the pagination for the volume as a whole. They may bear a 
section number within the overall volume, or may be separately 
identified. 

Figure 4-3 illustrates the section numbering rules that are 
employed when material in a section is rolled-out into a separate 
volume . 
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PRODUCT SPECIFICATION TEMPLATE 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose & Objectives of Volume 

1.4 Volume Status & Schedule 

1.5 Volume Organization & Roll-Out 

2.0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 

3.0 thru N.O SECTIONS OF THE PARENT SPECIFICATION BEING 

ROLLED-OUT INTO A SEPARATE VOLUME 

N+1.0 ABBREVIATIONS AND ACRONYMS 

N+2.0 GLOSSARY 

N+3 . 0 NOTES 

N+4 . 0 APPENDICES 


Figure 4-2. 


Product Specification Template. 
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ABC Parent Document 


1.0 Introduction 

2.0 Related Documentation 

3.0 Resources, etc... 


4.0 Topic A 

5.0 See Vol. B 

6.0 Topic C 

7.0 N/A 

N.0 Topic X 


N+1.0 Abbreviations & Acronyms 
N+2 .0 Glossary 
N+3.0 Notes 
N+4.0 Appendices 


Topic B Vol. of ABC Document 

1.0 Introduction 

1.1 Pointer to Parent Doc. 

2.0 Related Documentation 

3.0 Resources, etc... 


4.0 

Topic B.l 

5.0 

Topic B.2 

6.0 

Topic B.3 


6.1 Topic B.3.1 


6.2 Topic B.3.2 

7.0 

See Vol. B.4 

8.0 

Topic B.5 

9.0 

N/A 

M.O 

Topic B.Y 


M+1.0 Abbreviations & 
Acronyms 
M+2.0 Glossary 
M+3.0 Notes 
M+4.0 Appendices 


Topic B.4 Vol. of Topic B VoL 
of ABC Document 

1.0 Introduction 

1.1 Pointer to Topic B Vol. 

2.0 Related Documentation 

3.0 Resources, etc... 


X g 

Pa i 

ft P 
ft 


4.0 Topic B.4.1 

5.0 Topic B.4.2 

6.0 N/A 

7.0 Topic B.4.4 

P.0 Topic B.4.Z 


O 

o 



P+1.0 Abbreviations & 
Acronyms 
P+2.0 Glossary 
P+3.0 Notes 
P+4.0 Appendices 


H 

t-rt ^ 
° 2 
® U 

n» 


Figure 4-3. 
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4.4 The Product Specification Standard and Rules 

All of the standards contained in the parent document 
/ Inf ormation System Life— Cycle and Documentation Standards) shall 
apply to product specifications. This section contains 
additional rules that are specific to documentation. 

For the information system itself, and for each subordinate 
information system (subsystem) and software, hardware, and 
operational procedures component identified in the decomposition 
tree, the following standards shall apply: 

1) There shall be a single product specification document 
consisting of one or more volumes. Product specifications 
shall exactly follow the outline specified by the DIDs m 
Section 7. 

2) The manager of the development provider shall be respon- 
sible for designating the sections to be rolled-out as 
separate volumes and shall record the structure and content 
for the product specification in the development plan sec- 
tion of the management plan for the information system or 
component for which the specification is being prepared. 

3) If there are additional product specifications for support 
products, the responsible developer shall determine the 
structure and content for the product specification and 
shall describe them in the appropriate section of the 
management plan. The plan for assuring each support product 
shall be described in the appropriate section of the manage- 
ment plan, and assurance specifications, procedures, cri- 
teria, and results shall be documented in the appropriate 
sections of the assurance specification. 

4) The following rules shall be applied when generating a 
product specification: 

a) The roll-out of a section into a separate volume shall 
follow the standard format specified by the Product 
Specification Template DID (SMAP-DID-P999) given in 
Section 7 . 

b) The development provider has overall responsibility for 
the generation of the product specification for the . 
information system or component. This product specifi- 
cation shall be based on requirements allocated from the 
next higher node in the decomposition tree and any addi- 
tional requirements specified in the acquisition section 
of the management plan. 

c) Each rolled— out volume shall be titled as illustrated 
below. This method supports the standard and enables 
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one to place the volume in context with its parent (s) . 

< title of the rolled-out section > 

Volume of the 
[ < parent volume title > 

Volume of the ] 

< documentation set parent title > 

Document 

Note that the volume entry in brackets ( [ ] ) above is to 
be expanded zero or more times depending on the number 
of levels of roll-out from the documentation set parent. 
Additional information may be included on the title page 
as specified by delivery requirements. 

d) When writing the product specification document, the 
outline specified by the product specification (top 
level) DID shall be used. If more detailed structuring 
is needed for a section than that shown in this DID, then 
the structuring shall follow the detailed, rolled-out, 
DID(s) for for that section. Additional substructure 
detail (i.e., below the lowest level DID outline) may be 
added at the discretion of the author. 

Sections or subsections may be added if needed to convey 
technical information additional to that specified in the 
DIDs. Added sections or subsections shall be inserted 
following those specified in the DIDs. 

e) A section shall either: 
o contain information? 

o point to a lower level volume rolled-out from this 
document or volume? 

o point to another document (e.g., the contract 

governing the effort) that contains the information 
appropriate to the section? 

o be marked TBD (to be determined) if appropriate 
information is not yet available? or 

o be marked "Not applicable" or "None." 

If a section is "Not applicable" or "None," then none of 
its subordinate sections shall appear. 

f) The documentation standard designates a unique place for 
each element of information. The same information shall 
not be incorporated in more than one place when gen- 
erating a document or rolled-out volume. 
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g) The manager responsible for the product specification may 
roll-out beyond the roll-out structure implied by the DIDs 
in Section 7 of this volume. In that case the Product 
Specification Template DID (SMAP-DID-P999) shall be used. 

h) Any document that is to be placed under any level of 
an organization's configuration management shall be 
compatible with the appropriate electronic formats 
specified in applicable support environment (s) (such as 
the SSE and TMIS documentation formats for the Space 
Station Freedom Program.) 
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5. CL* APPLICATION AND SUPPORT OF THE PRODUCT SPECIFICATION 
DOCUMENTATION STANDARD 

This section provides guidelines for tailoring and using this 
standard to prepare a product specification or portion thereof. 


5 . 1 Guidelines 

The following collection of guidelines is offered to assist in 
applying this standard. 


5.1.1 How to Use the DIDs to Prepare a Product Specification 

To prepare a product specification for an information system, 
start with the Information System Product Specification DID 
( SMAP-DI D-POOO-SY) . For a software, hardware, or operational 
procedures component, start with the corresponding Product 
Specification DID for that component ( SMAP-DI D-POOO-SW, -HW, 

-OP) . (For a support product, select the type of product 
specification DID on the basis of which is most applicable to the 
product being developed. ) 

It is the responsibility of the development manager for that 
information system or component to determine for the product 
specification, and record in the development plan section of the 
management plan: 

1) Which sections are relevant and which should be marked 
"Not applicable” or "None." 

2) What level of detail is required for each section. 

3) Which sections will be rolled-out as separate volumes. 

4) Who will be responsible for the activities covered by a 
section, and therefore will be also responsible for pre- 
paring that section or volume. 

Thus the management plan provides overall direction as to the 
format of the product specification. 

The DIDs in Section 7 of this volume are presented in a rolled- 
out format. If the product specification is to be contained in 
one volume, then prepare Sections 1, 2, and the Abbreviations and 
Acronyms, Glossary, Notes, and Appendices sections as specified 
in the Product Specification Template DID ( SMAP-DI D-P9 9 9 ) . Then, 
for each section in the Product Specification DID ( SMAP-DI D-PO 00 
-SY, -SW, -HW, -OP) to be included inline, determine: 

a) If the amount of information to be included can be conveyed 
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in a few paragraphs, without subsections, then do so. How- 
ever, look over the detailed DID cited in that section of 
the top level DID to be sure that all appropriate informa- 
tion is included. 

b) If the amount or detail of the information to be included 
warrants use of subsections, then use the structure of 
the cited detailed DID as the substructure for that 
section. For example, section 3.0 in the detailed DID shall 
appear as Section N.l in the document? Section 4.0 in the 
detailed DID shall appear as Section N.2 in the document, 
and so on (where N stands for the corresponding section in 
the top level DID). Similarly, Section 3.1 in the detailed 
DID shall appear as Section N.1.1 in the document. See 
Figure 5-1 for an example of incorporating substructure from 
detailed DIDs into the inline structure for a section. 

Each document subsection specified in the detailed DID 
shall be included and shall be prepared in accordance with 
the rules stated in Section 4 of this documentation 
standard. If the detailed DID itself cites another 
detailed DID, it is necessary to follow the structure 
indicated by the latter DID only if further subsections 
are required. 

c) Additional sections and subsections may be included as 
described by the rules in Section 4. 

If the product specification is to be contained in multiple 
volumes, then for the sections that are rolled-out into separate 
volumes, use the appropriate DID in Section 7 or the rules for 
rolling-out a section. 


5.1.2 Roll-Out Factors 

Factors influencing a roll-out decision include: 

a) When the activities to be accomplished are delegated to 
another organization, whether internal or external. 

b) When the detail occasioned by the complexity of the 
activities to be accomplished is too great to be described 
within a single physical volume. 

c) When it is desirable to apply configuration management and 
control to the section separately from other sections be-^ 
cause of amount of change expected, time required to review 
before baselining, etc. 
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d) When it is desirable to have a separate volume for each 
life-cycle phase, and to control its updating separately 
within that phase. 


5.1.3 Documentation Content 

Documentation should be as brief and specific as possible while 
conveying all essential information. To aid in meeting this 
goal: 

a) If a section has subsections, content information should, 
in general, be contained within the subsections rather than 
under the section heading. Reserve the use of text under 
section headings, in cases where detailed information is 
provided in subsections, for such essentials as: 

o General explanatory information needed to aid the reader 
in understanding the detailed information following 

o Information common to two or more of the subsections 
following 

Do not write "boilerplate” that does not contain any data 
of substance? e.g. , a list of the topics covered in the 
subsections, or a promise to "do good things". 

b) Avoid redundancy. The hierarchical structure specified by 
the documentation standard and the DIDs provides a unique 
place to put each item of information needed, for most 
cases . 

c) Except where required by this standard, do not summarize 
the content of a rolled-out section in the parent document 
or volume. The summary might have to be changed each time 
the rolled-out section is changed. 


5.1.4 Transition from Current Data Requirements Lists 

During the period of transition while this standard is introduced 
into an ongoing NASA activity, the following considerations 
apply. 

a) Documents specified by an existing Data Requirements List 
(DRL) may closely parallel rolled-out sections as described 
in this documentation standard. When revising the DRL, or' 
if no specific outline is provided, it may be convenient to 
follow the appropriate DIDs presented in section 7. 

b) As an aid to establishing an easily-managed documentation 
set for an application, if it does not currently exist, it 
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may be desirable to prepare the top level documentation set 
document specified by this standard. This document can 
serve as an index to existing documentation by pointing to 
the appropriate DRL for each section. This provides then a 
relationship structure (or documentation tree) for pieces of 
existing data. More importantly, preparation of the docu- 
ment may highlight gaps in coverage for information needed 
to manage and produce the information system or component. 


5.1.5 Use of a Standards and Procedures Repository 

Acquirer and provider managers are responsible for determining 
the need and establishing a repository for any additional 
procedures, guidelines, rules, and practices for documentation 
that are not already defined in an existing repository, (such as 
the ones maintained for the Space Station Freedom Program by TMIS 
and the SSE) , or a parent information system or component 
repository. At the manager* s discretion, procedural information 
for minor or unique matters may be included as added subsections 
in a documentation set document (per rule for additional 
sections) . 

Please note that interfaces (such as those between two 
information systems) are not necessarily standards, but are part 
of the product specifications* interface requirements and 
design. 


5.2 Tools Supporting the Application and Use of the 
Documentation Standard 

Support environments may provide tools for the application and 
use of the documentation standard. For example, TMIS and the SSE 
provide tools for the Space Station Freedom Program that support 
the documentation standards. Such tools are used when preparing, 
reviewing, revising, publishing, distributing, and configuration 
managing documents. Tools are also provided for preparing a WBS 
and schedules. Tool support of the standards is the 
responsibility of the program/project. 
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6.0 ASSURANCE AND ENFORCEMENT OF THE DOCUMENTATION STANDARD 

If the SMAP information system life-cycle and documentation 
standards have been selected as standards by program/project 
management, then it is the responsibility of the acquiring 
manager of the information system or component to assure and 
enforce this documentation standard for all documentation written 
for that information system or component. 

The assurance process is formally addressed in one of two ways: 

1) As a quality assurance activity during the phase transition 
reviews indicated by the information system life-cycle. 

2) As explicitly called for within any planning document. 

(For example, an assurance plan section of the management 
plan could call for special reviews of individual documents 
and volumes . ) 

The information system life-cycle specifies that the initial 
version of the product specification is to be generated by the 
end of the information system project concept and initiation 
phase. This version of the product specification is reviewed at 
the end of that phase. 

The information system life-cycle also specifies that new 
sections of the product specification are to be prepared and 
reviewed during later phases of the life-cycle. This life-cycle 
standard also specifies that a product specification is reviewed 
as it is updated. 

It is the responsibility of the reviewers of any product 
specification to be familiar with the product specification 
documentation standard and to question any deviations from this 
standard. 

Because all sections specified in a DID must be included in the 
document or volume, managers and participants in management 
reviews can easily verify that all necessary information has been 
prepared. The structure for the document serves as a gross level 
checklist. 
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7.0 DATA ITEM DESCRIPTIONS (DIDS) 

This section contains the specifications for the format, outline, 
and content of the product specification document and of 
rolled-out sections. 

Because presenting the outline for the product specification as a 
single DID is overwhelming and unmanageable, major sections have 
been rolled-out into separate DIDs using the standard roll-out 
template. This provides traceability to Version 3 DIDs and ease 
of use and packaging. However, if it is desirable to create the 
product specification as a single document, the detailed table of 
contents for such a document is presented in the appendices 
section of this volume. 

The number of product specification volumes generated for a 
specific information system or component need not mirror the 
number of DIDs presented in this section. Lower-level detailed 
DIDs provide additional substructure and contain content 
discussion which should be reviewed even when the content is 
recorded in-line (i.e., not rolled-out). In general, one would 
start with the appropriate SMAP-DID-P000 using the guidelines in 
Section 5. Documentation authors then decide to what level the 
product specification is to be rolled-out. (If no DID is cited, 
then additional substructure is at the discretion of the author. ) 

Tables 7-1 through 7-6 are provided to assist the users of these 
standards. Table 7-1 contains a listing of the DIDs by DID 
number (from the Table of Contents) . Table 7-2 contains a list 
of the DIDs by DID title. Table 7-3 depicts the relationships 
among the product specification DIDs for an information system. 
Table 7-4 depicts the relationships among the software product 
specification DIDs? Table 7-5 for the hardware product 
specification DIDs; and Table 7-6 for the operational procedures 
product specification DIDs. Each level of indentation in Tables 
7-3 through 7-6 reflects an additional level of DID detail and 
substructure. Tables 7-3 through 7-6 are not to be taken as a 
roll-out structure for any particular product specification. 

The Template DID (SMAP-DID-P999) provides detailed instructions 
for preparing the sections that are common to the document and 
all volumes rolled-out from the document. Note that this DID 
does not itself represent a particular separate document or 
volume, but is used to generate a volume format for a section 
that a manager wishes to document in a separate volume. 

The four Product Specification DIDs (SMAP-DID-P000-SY, -SW, -HW, 
-OP) provide outlines for the complete product specification 
documents for an information system and for a software component, 
hardware component, or operational procedures component. Major 
sections of these DIDs point to those DIDs that contain detailed 
descriptions for the content of those sections. 
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The detailed DIDs in section 7 may be used as they stand to 
produce separate volumes of a product specification. If the 
section represented by a detailed DID is to be presented, 
instead, as an inline part of a product specification document, 
then only those sections from 3.0 to (but not including) the 
Abbreviations and Acronyms section are to be used. (See Section 
5.1.1 for further discussion.) 
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TABLE 7-1. DID Index (Numeric Order) . 


SMAP-DID-POOO-SY Information System Product 

Specification DID 27 

SMAP— DID-POOO-SW Software Product Specification 

DID 32 

SMAP-DI D-PO 0 0 -HW Hardware Product Specification 

DID 37 

SMAP-DI D-PO 00 -OP Operational Procedures Product 

Specification DID 43 

SMAP-DID-P100 Concept DID 48 

SMAP-DID-P2 00-SY Information System Requirements 

DID 53 

SMAP-DI D-P200-SW Software Requirements DID 59 

SMAP-DID-P200-HW Hardware Requirements DID 65 

SMAP-DID-P200-OP Operational Procedures 

Requirements DID 71 

SMAP-DID-P210 External Interface Requirements 

DID 76 

SMAP-DI D-P3 00-SY Information System Design DID ... 79 

SMAP-DI D-P3 00 -OP Operational Procedures Design 

DID 83 

SMAP-DID-P3 10-SW Software Architectural Design 

DID 86 

SMAP-DID-P310-HW Hardware Architectural Design 

DID 90 

SMAP-DID-P311-SY Information System External 

Interface Design DID 94 

SMAP-DI D-P3 11 -SW Software External Interface 

Design DID 97 

SMAP-DID-P311-HW Hardware External Interface 

Design DID 100 

SMAP-DID-P320-SW Software Detailed Design DID .... 103 

SMAP-DID-P320-HW Hardware Detailed Design DID .... 108 

SMAP-DI D-P3 2 1-SW Software External Interface 

Detailed Design DID 112 

SMAP-DID-P3 2 1-HW Hardware External Interface 

Detailed Design DID 116 

SMAP-DID-P3 2 2 -SW (Software) Firmware Support 

Manual DID 119 

SMAP-DID-P400 Version Description DID 124 

SMAP-DID-P4 10-OP Operational Procedures Manual 

DID 128 

SMAP-DID-P500 User's Guide DID 132 

SMAP-DID-P600-SY Information System Maintenance 

Manual DID 136 

SMAP-DI D-P600-SW Software Maintenance Manual DID . 139 

SMAP-DID-P600-HW Hardware Maintenance Manual DID . 142 

SMAP-DI D-P9 20 Standards and Guidelines DID .... 145 

SMAP-DID-P999 Product Specification Template 

DID 149 
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TABLE 7-2. DID Index (Alphabetic Order) 


Concept DID 

External Interface Requirements DID 
Hardware Architectural Design DID 
Hardware Detailed Design DID 
Hardware External Interface Design DID 
Hardware External Interface Detailed 
Design DID 

Hardware Maintenance Manual DID 
Hardware Product Specification DID 
Hardware Requirements DID 
Information System Design DID 
Information System External Interface 
Design DID 

Information System Maintenance Manual 
DID . . 

Information System Product Specifica- 
tion DID 

Information System Requirements DID 
Operational Procedures Design DID 
Operational Procedures Manual DID 
Operational Procedures Product 
Specification DID 

Operational Procedures Requirements 
DID 

Product Specification Template DID 
Software Architectural Design DID 
Software Detailed Design DID 
Software External Interface Design DID 
Software External Interface Detailed 
Design DID 

(Software) Firmware Support Manual DID 
Software Maintenance Manual DID 
Software Product Specification DID 
Software Requirements DID 
Standards and Guidelines DID 
User's Guide DID 
Version Description DID 


SMAP-DID-P100 

48 

SMAP-DID-P2 10 

76 

SMAP-DID-P3 10-HW 

90 

SMAP-DID-P3 2 0-HW 

108 

SMAP-DID-P3 1 1-HW 

100 

SMAP-DID-P3 2 1-HW 

116 

SMAP-DID-P600-HW 

142 

SMAP-DID-P000-HW 

37 

SMAP-DID-P2 00-HW 

65 

SMAP-DID-P300-SY 

79 

SMAP-DID-P3 11-S Y 

94 

SMAP-DID-P600-SY 

136 

SMAP-DID-P000-SY 

27 

SMAP-DID-P2 00-SY 

53 

SMAP-DID— P300-OP 

83 

SMAP-DID— P410-0P 

128 

SMAP-DID-POOO-OP 

43 

SMAP-DID-P2 OO-OP 

71 

SMAP-DID-P999 

149 

SMAP-DID-P3 10-SW 

86 

SMAP-DID-P320-SW 

103 

SMAP-DID-P3 11-SW 

97 

SMAP-DID-P3 2 1-SW 

112 

SMAP-DID-P3 2 2-SW 

119 

SMAP-DID-P600-SW 

139 

SMAP-DID— POO 0-SW 

32 

SMAP-DID-P2 0 0-SW 

59 

SMAP-DID-P9 2 0 

145 

SMAP-DI D-P5 0 0 

132 

SMAP-DI D-P4 0 0 

124 
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TABLE 7-3. Complete DID Set for an Information System 
Product Specification. 


SMAP-DID-POOO-SY Information System Product 

Specification DID 
SMAP-DID-P100 Concept DID 

SMAP-DID-P2 OO-SY Information System Requirements DID 
SMAP-DID-P2 10 External Interface Requirements DID 
SMAP-DID-P3 00-SY Information System Design DID 
SMAP-DID-P3 11-SY Information System External 

Interface Design DID 

SMAP-DID-P400 Version Description DID 
SMAP-DID-P500 User's Guide DID 
SMAP-DID-P6 00-SY Information System Maintenance 

Manual DID 


TABLE 7-4. Complete DID Set for a Software 
Product Specification. 


SMAP— DID-P000-SW Software Product Specification DID 
SMAP-DID-P100 Concept DID 
SMAP-DID-P2 0 0-SW Software Requirements DID 

SMAP-DID-P2 10 External Interface Requirements DID 

SMAP-DID-P310-SW Software Architectural Design DID 
SMAP-DID-P3 11-SW Software External Interface 

Design DID 

SMAP-DID-P3 2 0-SW Software Detailed Design DID 
SMAP-DID-P3 2 1-SW Software External Interface 

Detailed Design DID 

SMAP-DID-P322-SW (Software) Firmware Support 

Manual DID 

SMAP-DID-P400 Version Description DID 

SMAP-DID-P500 User's Guide DID 

SMAP-DID-P600-SW Software Maintenance Manual DID 
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TABLE 7-5. Complete DID Set for a Hardware 
Product Specification. 


SMAP-DID-POOO-HW Hardware Product Specification DID 
SMAP-DID-P100 Concept DID 
SMAP-DID-P200-HW Hardware Requirements DID 

SMAP-DID-P2 10 External Interface Requirements DID 

SMAP-DID-P310-HW Hardware Architectural Design DID 
SMAP-DID-P311-HW Hardware External Interface 

Design DID 

SMAP-DID-P3 2 0-HW Hardware Detailed Design DID 
SMAP-DID-P3 2 1-HW Hardware External Interface 

Detailed Design DID 

SMAP-DI D-P4 0 0 Version Description DID 

SMAP-DID-P500 User * s Guide DID 

SMAP-DI D-P60 0-HW Hardware Maintenance Manual DID 


TABLE 7-6. Complete DID Set for an Operational Procedures 
Product Specification. 


SMAP-DID-POOO-OP Operational Procedures Product 

Specification DID 
SMAP-DI D-Pl 00 Concept DID 
SMAP-DID-P2 OO-OP Operational Procedures 

Requirements DID 

SMAP-DID-P3 OO-OP Operational Procedures Design DID 
SMAP-DI D-P4 00 Version Description DID 

SMAP-DID-P410-OP Operational Procedures Manual DID 
SMAP-DID-P500 User's Guide DID 
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SMAP-DID-POOO-SY 

INFORMATION SYSTEM PRODUCT SPECIFICATION 
DATA ITEM DESCRIPTION 

TABLE OF CONTENTS 

Section 

1.0 INTRODUCTION 

2 . 0 RELATED DOCUMENTATION 

3 . 0 CONCEPT 

4 . 0 REQUIREMENTS 

5.0 DESIGN 

6 . 0 VERSION DESCRIPTION 

7.0 USER AND OPERATOR DOCUMENTATION 

7 . 1 User 1 s Guide 

7.2 User's Training Materials 

7.3 Operator's Training Materials 

8.0 MAINTENANCE MANUAL 

9.0 ABBREVIATIONS AND ACRONYMS 

10.0 GLOSSARY 

11.0 NOTES 

12 . 0 APPENDICES 
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EXPLANATORY NOTE 

The purpose of an information system product specification 
is to document the technical aspects relative to the 
development of the information system. This information is 
produced over the life— cycle for the information system. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P9 99) . 


3 . 0 CONCEPT 

The purpose of this section is to provide an overview of the 
information system. It provides the scope and context in which 
to read the requirements section. 

The primary topics for the concept specification include: 

o Definition and Purpose 
o User Definition 

o Capabilities and Characteristics 
o Sample Operational Scenarios 

Refer to the Concept DID (SMAP-DID-P100) for a further 
description of the structure and content. 


4 . 0 REQUIREMENTS 

The purpose of this section is to specify the functional, 
performance, and interface requirements of the information 
system. It also specifies the major characteristics and 
implementation constraints, and the design goals. 

The primary topics for the requirements specification include: 

o Requirements Approach and Tradeoffs 
o External Interface Requirements 
o Information System Requirements 
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o Traceability to Parent’s Design 
o Partitioning for Phased Delivery 

Refer to the Information System Requirements DID (SMAP-DID- 
P200-SY) for a further description of the structure and content 
for each topic. 


5.0 DESIGN 

The purpose of the system design section is to record the design 
rationale, provide an architecture of the major subsystems or 
components for the information system, and allocate requirements 
to the architectural components. 

The primary topics for the design specification include: 

o Design Approach and Tradeoffs 
o External Interfaces Design 
o Architectural Design 
o Requirements Allocation 
o Traceability to Requirements 
o Partitioning for Incremental Development 

Refer to the Information System Design DID (SMAP-DID-P300-SY) for 
a further description of the structure and content for each 
topic . 


6.0 VERSION DESCRIPTION 

The purpose of this section is to describe in detail the 
configuration and content of the product and instructions for its 
set-up. For each new release, the section also provides 
information on the status of changes since previous releases. 

The primary topics for the version description include: 

o Changes in Functional Capabilities 
o Set-up Instructions 
o Inventory of Actual Products 
o Change Status 
o Adaptation Data 

Refer to the Version Description DID (SMAP-DID-P400) for a 
further description of the structure and content for each topic. 
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7.0 USER AND OPERATOR DOCUMENTATION 


7 . 1 User 1 s Guide 

The purpose of the user's guide for the information system is to 
provide end users (as opposed to system operators) with 
instructions explaining how to employ and execute the functions 
provided by the system. Users include both human users and 
interfacing systems. The user's guide documents the actual 
implementation of the external interfaces (i.e., interfaces for 
users) as defined in the requirements and design sections. 
Instructions for operators, on the other hand, are contained in 
the Operational Procedures Manual that is the product of the 
operational procedures component (i.e., there is a distinction 
between operators and users) . 

The system user's guide may include a compendium of the user's 
guides for the system's subsystems or components, which can be 
incorporated via reference. 

The primary topics for the User's Guide include: 

o Installation and Initialization 
o Overview of Purpose and Functions 
o Startup and Termination 
o Functions and their Operation 
o Error and Warning Messages 
o Recovery Steps 

Refer to the User's Guide DID (SMAP-DID-P500) for a further 
description of the structure and content under each topic. 


7.2 User's Training Materials 

The purpose of this section is to document the training materials 
provided for the users. This is the actual training materials. 
When media is other than paper hardcopy, describe media and 
reference the training materials such as video tapes and 
computer-aided instruction files. 


7.3 Operator's Training Materials 

The purpose of this section is to document the training materials 
provided for the operators. (Operators execute the operational" 
procedures of an information system as documented in the 
Operational Procedures Manual.) These are the actual training 
materials. When media is other than paper hardcopy, describe 
media and reference the training materials such as video tapes 
and computer-aided instruction files. 
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8.0 MAINTENANCE MANUAL 

The purpose of the maintenance manual for the information system 
is to provide maintenance engineers with information to aid them 
in maintaining the system. The manual may be a compendium of 
maintenance manuals for the components augmented with systems 
aspects. The component maintenance information may be included 
via reference to their appropriate maintenance manuals. Refer to 
the Information System Maintenance Manual DID (SMAP-DID-P600-SY) 
for a further description of the structure and content. 


9.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

10.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

11.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DI D-P9 9 9 ) 
for the detailed description of content for this section. 

12 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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SMAP-DID-POOO-SW 
SOFTWARE PRODUCT SPECIFICATION 
DATA ITEM DESCRIPTION 

TABLE OF CONTENTS 

Section 

1.0 INTRODUCTION 

2 . 0 RELATED DOCUMENTATION 

3 . 0 CONCEPT 

4 . 0 REQUIREMENTS 

5.0 DESIGN 

5 . 1 Architectural Design 

5.2 Detailed Design 

6 . 0 VERSION DESCRIPTION 

7 . 0 USER DOCUMENTATION 

7 . 1 User • s Guide 

7.2 User's Training Materials 

8 . 0 MAINTENANCE MANUAL 

9.0 ABBREVIATIONS AND ACRONYMS 

10.0 GLOSSARY 

11.0 NOTES 

12.0 APPENDICES 


32 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENT STANDARD 
SOFTWARE PRODUCT SPECIFICATION DID: SMAP-DID-POOO-SW 


EXPLANATORY NOTE 

The purpose of an software product specification is to 
document the technical aspects relative to the development 
of the software. This information is produced over the 
life-cycle for the software component. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing . 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 CONCEPT 

The purpose of this section is to provide an overview of the 
software component. When required, this section provides the 
scope and context to help in understanding the requirements. 
Depending upon the system decomposition and the size and 
complexity of the parent information system or component, this 
section may not be needed and, therefore, should be marked not 
applicable. 

The primary topics for the concept specification include: 

o Definition and Purpose 
o User Definition 

o Capabilities and Characteristics 
o Sample Operational Scenarios 

Refer to the Concept DID (SMAP-DID-P100) for a further 
description of the structure and content. 


4 . 0 REQUIREMENTS 

The purpose of this section is to specify and augment, as 
appropriate, the functional, performance, and interface 
requirements allocated to this software component from its 
parent. The section also specifies the major characteristics, 
implementation constraints, and design goals. 
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The primary topics for the requirements specification include: 

o Requirements Approach and Tradeoffs 
o External Interface Requirements 
o Software Requirements 
o Traceability to Parent* s Design 
o Partitioning for Phased Delivery 

Refer to the Software Requirements DID (SMAP-DID-P200-SW) for a 
further description of the structure and content for each topic. 


5 . 0 DESIGN 


5.1 Architectural Design 

The purpose of the architectural design is to document the top 
level, comprehensive design for the software component (which may 
consist of one or more computer software configuration items) , 
including major external and internal interfaces and logical data 
schema. In addition, the section should include an explanation 
of the rationale for the architecture. 

The primary topics for the architectural design specification 
include: 

o Design Approach and Tradeoffs 
o External Interface Design 
o Architecture Design Description 
o Traceability to Requirements 
o Partitioning for Incremental Development 

Refer to the Software Architectural Design DID ( SMAP-DID-P3 10-SW) 
for a further description of the structure and content for each 
topic . 

5 . 2 Detailed Design 

The purpose of this section is to describe the design for the 
software component in detail sufficient to write the software 
code to implement it. Detailed design defines the structure and 
functions of each computer software configuration item down to 
the computer software unit level. 

The primary topics for the detailed design specification includes 

o Detailed Design Approach and Tradeoffs 
o External Interfaces Detailed Design 
o Detailed Design 

o Traceability to Architectural Design 
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Refer to the Software Detailed Design DID (SMAP-DID-P320-SW) for 
a further description of the structure and content for each 
topic . 


6 . 0 VERSION DESCRIPTION 

The purpose of this section is to describe in detail the 
configuration and content of the product and instructions for its 
set-up. For each new release, the section also provides 
information on the status of changes since previous releases. 

The primary topics for the version description include: 

o Changes in Functional Capabilities 
o Set-up Instructions 

o Inventory and Software Product Identification 
o Change Status 
o Adaptation Data 

Refer to the Version Description DID ( SMAP-DI D-P4 00) for a 
further description of the structure and content for each topic. 


7 . 0 USER DOCUMENTATION 


7 . 1 User 1 s Guide 

The purpose of the software User's Guide is to provide end users 
(human and other systems) with instructions on the use of this 
software component. Because the software is an integral 
component of an information system, this guide may be prepared as 
source material for a integrated information system user's guide 
for the parent information system. (There is also similar 
applicability if this is a software subcomponent and an 
integrated parent level software user's guide is desired.) In 
such cases, then it may be advisable to roll-out this section as 
a separate volume. 

The primary topics for the User's Guide include: 

o Installation and Initialization 
o Overview of Purpose and Functions 
o Startup and Termination 
o Functions and their Operation 
o Error and Warning Messages 
o Recovery Steps 

Refer to the User's Guide DID (SMAP-DID-P500) for a further 
description of the structure and content under each topic. 
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7.2 User's Training Materials 

The purpose of this section is to document the training materials 
provided for the users. This is the actual training materials. 
When media is other than paper hardcopy, describe media and 
reference the training materials such as video tapes and 
computer-aided instruction files. 


8 . 0 MAINTENANCE MANUAL 

The purpose of this section is to provide information and data 
that aids in analyzing and debugging the software and which is 
not contained in other documentation. 

Refer to the Software Maintenance Manual DID ( SMAP-DI D-P 6 0 0- S W ) 
for a further description of the structure and content for each 
topic . 


9.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DI D-P9 99) 
for the detailed description of content for this section. 


12 . 0 APPENDICES 

Refer to the Product Specification Template DID ( SMAP-DI D-P9 99) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of a hardware product specification is to 
document the technical aspects relative to the development 
of the hardware component. This information is produced 
over the life-cycle for the hardware component. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P9 99) . 


3 . 0 CONCEPT 

The purpose of this section is to provide an overview of the 
hardware component. When required, this section provides the 
scope and context to help in understanding the requirements. 
Depending upon the system decomposition and the size and 
complexity of the parent information system or component, this 
section may not be needed and, therefore, should be marked not 
applicable. 

The primary topics for the concept specification include: 


o Definition and Purpose 
o User Definition 

o Capabilities and Characteristics 
o Sample Operational Scenarios 

Refer to the Concept DID (SMAP-DID-P100) for a further 
description of the structure and content. 


4 . 0 REQUIREMENTS 

The purpose of this section is to specify and augment, as 
appropriate, the functional, performance, and interface . 
requirements allocated to this hardware component . from its parent 
in the decomposition tree. The section also specifies the major 
characteristics, implementation constraints, and design goals. 
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The primary topics for the requirements specification include: 

o Requirements Approach and Tradeoffs 
o External Interface Requirements 
o Hardware Requirements 

o Implementation Constraints, including Commercial, 
Inheritable, and Government-Furnished Hardware 
o Traceability to Parent's Design 

Refer to the Hardware Requirements DID ( SMAP-DID-P200-HW) for a 
further description of the structure and content for each topic. 


5.0 DESIGN 


5 . 1 Architectural Design 

The purpose of the architectural design is to document the top 
level, comprehensive design for the hardware component (which may 
consist of one or more hardware configuration items) , including 
its major external and internal interfaces. In addition, the 
section should include an explanation of the rationale for the 
selected architecture. 

The primary topics for the architectural design specification 
include: 

o Design Approach and Tradeoffs 
o External Interface Design 
o Architectural Design Description 
o Traceability to Requirements 
o Partitioning for Incremental Development 

Refer to the Hardware Architectural Design DID ( SMAP-DID-P3 10-HW) 
for a further description of the structure and content for each 
topic . 


5 . 2 Detailed Design 

The purpose of this section is to describe the design for the 
hardware component in detail sufficient to fabricate it. 

Detailed design identifies the assemblies making up each hardware 
configuration item, and the line replaceable units (LRUs) making 
up each assembly. 

The primary topics for the detailed design specification include: 

o Detailed Design Approach 
o External Interfaces Detailed Design 
o Detailed Design Description 
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o Traceability to Architectural Design 

Refer to the Hardware Detailed Design DID (SMAP-DID-P320-HW) for 
a further description of the structure and content for each 
topic. 


6 . 0 VERSION DESCRIPTION 

The purpose of this section is to describe in detail the 
configuration and content of the product and instructions for its 
set-up. For each new release, the section also provides 
information on the status of changes since previous releases. 


The primary topics for the version description include: 

o Changes in Functional Capabilities 
o Set-up Instructions 

o Inventory and Hardware Product Identification 
o Change Status 
o Adaptation Data 

Refer to the Version Description DID (SMAP-DID-P400) for a 
further description of the structure and content for each topic. 


7 . 0 USER DOCUMENTATION 


7 . 1 User 1 s Guide 


The purpose of the hardware User's Guide is to provide end users 
(humans and other systems) with instructions on the use of this 
hardware component. As a hardware component is often an integral 
component of an information system, this guide may be prepared as 
source material for a integrated information system user s guide 
for the parent information system. (There is also similar 
applicability if this is a hardware subcomponent and an 
integrated parent level hardware user's guide is desired.) In 
such cases, then it may be advisable to roll-out this section as 

a separate volume. 

The primary topics for the User's Guide include: 


o Installation and Initialization 
o Overview of Purpose and Functions 
o Startup and Termination 
o Functions and their Operation 
o Error and Warning Messages 
o Recovery Steps 

Refer to the User's Guide DID (SMAP-DID-P500) for a further 
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description of the structure and content under each topic. 


7.2 User's Training Materials 

The purpose of this section is to document the training materials 
provided for the users. This is the actual training materials. 
When media is other than paper hardcopy, describe media and 
reference the training materials such as video tapes and 
computer-aided instruction files. 


8 . 0 MAINTENANCE MANUAL 

The purpose of this section is to provide information and data 
that aids in analyzing and debugging the hardware, and which is 
not contained in other documentation. 

The primary topics for the maintenance manual include: 

o Problem Detection and Isolation 
o Environmental Sensitivity 
o Built-in Test Diagnostics 

Refer to the Hardware Maintenance Notes DID (SMAP-DID-P600-HW) 
for a further description of the structure and content for each 
topic . 


9.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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12 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of an operational procedures product 
specification is to document such procedures and associated 
technical aspects of the procedures. This information is 
produced over the life-cycle for the operational procedures 
component . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 CONCEPT 

The purpose of this section is to provide an overview of the 
operational procedures component. When reguired, this section 
provides the scope and context to help in understanding the 
requirements. Depending upon the system decomposition and the 
size and complexity of the parent information system or 
component , this section may not be needed and, therefore, should 
be marked not applicable. 

The primary topics for the concept specification include: 


o Definition and Purpose 
o User Definition 

o Capabilities and Characteristics 
o Sample Operational Scenarios 

Refer to the Concept DID (SMAP-DID-P100) for a further 
description of the structure and content. 
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4 . 0 REQUIREMENTS 

The purpose of this section is to specify and augment, as 
appropriate, the functional, performance, and interface 
requirements allocated to this operational procedures component 
from its parent in the decomposition tree. The section also 
specifies the major characteristics, implementation constraints, 
and design goals. 

The primary topics for the requirements specification include: 

o Requirements Approach and Tradeoffs 
o External Interface Requirements 
o Operational Procedures Requirements 
o Traceability to Parent* s Design 
o Partitioning for Phased Delivery 

Refer to the Operational Procedures Requirements DID 
(SMAP-DID-P200-OP) for a further description of the structure and 
content for each topic. 


5.0 DESIGN 

The purpose of this section is to define the scenarios describing 
the manual operations required for the information system and 
their interface to software and hardware components. 

Refer to the Operational Procedures Design DID (SMAP-DID-P300-OP) 
for a further description of the structure and content under each 
topic . 


6 . 0 VERSION DESCRIPTION 

The purpose of this section is to describe in detail the 
configuration and content of the product and instructions for its 
set-up. For each new release, the section also provides 
information on the status of changes since previous releases. 

The primary topics for the version description include: 

o Changes in Functional Capabilities 
o Inventory and Operational Procedures Manual 
o Change Status 

Refer to the Version Description DID (SMAP-DID-P400) for a 
further description of the structure and content for each topic. 
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7.0 USER AND OPERATOR DOCUMENTATION 


7 . 1 User • s Guide 

The purpose of an operational procedures User’s Guide is to 
provide the end users with instruction on interfacing with 
operators. Because the operational procedures is an integral 
component of an information system, this guide may be prepared as 
source material for an integrated information system user’s guide 
for the parent information system. In such cases, then it may be 
advisable to roll-out this section as a separate volume. 

The primary topics included in the manual include: 

o Types of services available 
o Contact points for services 


7.2 User's Training Materials 

The purpose of this section is to document the training materials 
provided for the users. This is the actual training materials. 
When media is other than paper hardcopy, describe media and 
reference the training materials such as video tapes and 
computer-aided instruction files. 


7,3 Operator's Training Materials 

The purpose of this section is to document the training materials 
provided for the operators. (Operators execute the operational 
procedures of an information system as documented in the 
Operational Procedures Manual.) These are the actual training 
materials. When media is other than paper hardcopy, describe 
media and reference the training materials such as video tapes 
and computer-aided instruction files. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the concept is to provide an overview of the 
information system or component. The concept volume should 
be relatively brief — certainly fewer than 100 pages, 
including scenarios. Ideally, the concept should be 
readable in a single sitting. 

The concept provides the context in which to read the 
requirements section of the product specification for an 
information system or component. All requirements should 
be traceable, in a general sense, to the functions or 
capabilities described in the concept. However, the 
requirements section (or volume, if the section is 
rolled-out) , is the governing specification for the 
product. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DEFINITION OF < INFORMAT I ON SYSTEM OR COMPONENT> 

Throughout the presentation of the concept, the term "user" 
refers both to humans and to interfacing information systems and 
components . 


3.1 Purpose and Scope 

Briefly describe the purpose to be served by the information 
system or component that is the subject of this concept and the 
scope of its applicability. Describe the primary use(s) of the 
information system or component within the context of the users* 
environments . 
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3.2 Goals and Objectives 

Describe the goals (i.e., intentions and desires) for the 
information system or component, and the objectives (i.e., 
expectations) for it. 


3 . 3 Description 

Provide a top-level description of the information system or 
component and its major external interfaces to provide a 
background to aid the reader in understanding what the system or 
component is to accomplish. 

Use appropriate graphics, illustrations, tables, etc. to show 
functions and inter-relationships. 


3.4 Policies 

List or reference the policies and standards governing the use 
and applicability of this information system or component. If 
there are none, then so state. 


4.0 USER DEFINITION 

List and describe the expected users of the information system or 
component, the way in which they will be using the it, and the 
functional capabilities they will require to perform their 
activities. The term "user” includes interfacing systems and 
components. Define the users and their needs explicitly and in 
such terms and detail as to make it possible to correlate system 
capabilities and characteristics to specific user needs. 


5.0 CAPABILITIES AND CHARACTERISTICS 

Describe the major operational capabilities to be provided by the 
information system or component. Identify which . users ' . needs are 
supported by each capability. Use a table, matrix or similar 
graphic presentation if appropriate for the sake of clarity. 

Describe significant characteristics required of the information 
system or component. Possible areas of discussion are: 

o Architecture 
o Process capabilities 
o Data structures 
o Performance 
o Interfaces 

o Error recovery capabilities 
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o Reliability 
o Risk criticality 
o Safety and security 
o Maintainability 
o Flexibility and expansion 
o Transportability 
o Quality 

o Adaptation to various operational sites 
o Security 

o Phase implementation 
Discuss also: 

1) Characteristics of the current and potential physical 
and organizational environment for the system or 
component . 

2) The general flow of both execution control and data 
across external interfaces for the system or component, 
including hardware and networking considerations affecting 
system or component operation. 

If there are major design constraints imposed upon this 
information system or component, identify and describe each of 
them. 


6.0 SAMPLE OPERATIONAL SCENARIOS 

Describe typical operational scenarios for the information system 
or component. The scenario depicts at a high level how users 
(including other systems) interact with the capabilities provided 
by the information system or component being defined. Include at 
least one scenario for each class or type of user. 

A sample scenario would include such matters as: 

a) A description of an operation to be performed with support 
from the information system or component. 

b) A description of the interaction between a user and the 
information system or component in carrying out the 
operation. 
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7.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the information system requirements is to 
specify the functional, performance, and interface 
requirements for an information system. Requirements 
approach and tradeoff results are described. This section 
also specifies the major characteristics, implementation 
constraints, and design goals for the information system. 

For the sake of traceability to the lowest level of 
implementation, each requirement shall be uniquely 
identified. A hierarchical or other classification scheme 
may be used to designate requirements that are allocated by 
groups to higher— level components and functions. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 REQUIREMENTS APPROACH AND TRADEOFFS 

Describe the overall approach in gathering, analyzing, and 
synthesizing requirements, including use of prototyping 
techniques. Explain the tradeoff process used to analyze 
conflicting requirements and arrive at the actual specifications 
for those requirements. Requirements trades and analysis 
information (such as a prototyping effort report) , especially 
that which must be reevaluated or considered when changes are 
proposed during development or maintenance, should be included in 
an appendix or explicitly referenced. 


4.0 EXTERNAL INTERFACE REQUIREMENTS 

The purpose of this section is similar to that of the traditional 
interface requirements document? that is, it contains the 
specification of requirements for interfaces between this 
information system and its external environment (i.e., all its 
users including both humans and other systems) . This section 
should be rolled-out when it is desirable to place it under 
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configuration control as a separate item. When rolled-out, it 
becomes the external interface requirements volume. 

Refer to the External Interface Requirements DID (SMAP-DID-P210) 
for a further description of the content for this section. 


5 . 0 REQUIREMENTS SPECIFICATION 


5.1 Process and Data Requirements 

Describe, as a separately numbered item for the sake of 
traceability, the process and data requirements for the 
information system in such terms as: 

1) Functions: 

o Input data 
o Algorithms 
o Output data 
o State changes 

2 ) Data : 

o Definition 

o Acquisition, storage, retrieval, and dissemination 
o Relationships 

3 ) System control . 


5.2 Performance and Quality Engineering Requirements 

Specify, as a separately numbered item for the sake of 
traceability, each performance requirement for the system. 
Express the requirement in testable and quantitative terms. Be 
sure to prioritize these requirements. 

1) Address operational requirements such as: 

o Timing and sizing requirements 
o Capacity and operational frequency ranges 
o Response time ranges 

2) Describe quality engineering requirements, such as: 

o Reliability requirements including system failure rate 
probabilities as well as fault tolerance and recovery 
in terms of: 

- Recovery to normal operations from anomalous 
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conditions 


Data protection and recovery 


o Maintainability requirements 


3) Describe environmental characteristics affecting P er . 

formance, including transportation, storage, and deployment 
of the system, such as: 

o Natural environment: heat, pressure, moisture, etc. 


o Electromagnetic and other forms of radiation, including 
both those in the natural environment and those 
generated by the system 


o Magnetic environment 


o Hostile environment 

o Anticipated number of installations and their locations 


5.3 Safety Requirements 


Specify, as separately numbered items for the sake of 
traceability, the safety requirements for the information system, 
including, in a prioritized list, the following: 


o System hazard requirements which identifies hazards and 
potential contributions to system mishaps 

o System/user interface considerations from a human factors 
engineering viewpoint, including information flow, 
processing analysis, estimates of potential operator/ 
maintainer processing capabilities, and analysis of 
critical tasks. 


5.4 Security and Privacy Requirements 

Specify, as separately numbered items for the sake of 
traceability, the security and privacy requirements for the_ 
information system, including access limitations to the: system 
such as existence of logon procedures and passwords, and of d 
protection and recovery methods . Express each requirement in 
testable and quantitative terms. Prioritize these requirements. 
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5 . 5 Implementation Constraints 

Specify any constraints on the design or implementation of this 
information system. For example, specify whether the design must 
be based on use (or avoidance) of inheri tables , goveniment- 
furnished equipment (GFE) , commercial-off-the-shelf items, or the 
interface with an existing system. 

List or reference engineering and technical standards to be 
applied in the development of this information system. 


5.6 Site Adaptation 

Specify requirements for adapting or configuring the information 
system to the physical environments within which it operates, 
including site-specific adaptation data such as latitude and 
longitude, radar ranges , prescribed safety limits, etc. 
Adaptation requirements may be presented in tabular form. 


5 . 7 Design Goals 

When appropriate, describe specific design goals in prioritized 
order. When possible, criteria for meeting the design goal 
should be included in the statement. Examples of design goals 
include: 

o Correctness to the degree that the implemented system is 
to satisfy its requirements 

o Reliability of the implemented system to consistently 
perform its intended function 

o Efficiency with which the implemented system is to use 
computer resources 

o Maintainability 

o Technology transparency 


6.0 TRACEABILITY TO PARENT'S DESIGN 

Describe how these requirements map to the requirements allocated 
from the parent. Use a table for presentation as an aid to 
clarity, and show both that requirements allocated from the 
parent have been taken into account and that requirements 
specified herein cam be traced to the parent, or that there is a 
valid reason for introduction of any new requirements at this 
level . 


Release 4.3, 2/28/89 


57 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
INFORMATION SYSTEM REQUIREMENTS DID: SMAP-DID-P200-SY 


7.0 PARTITIONING FOR PHASED DELIVERY 

If phased delivery is to be employed in the development of the 
information system (i.e., each delivery must be acceptance 
tested), identify the content for each delivery in terms of: 

1) Requirements and functions to be satisfied in the 
initial delivery. 

2) Additional requirements and functions to be satisfied 
for each successive delivery. 

Note that incremental development or phased delivery decisions at 
a higher (parent) level information system may impose phased 
delivery requirements upon this information system. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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SMAP-DID-P200-SW 
SOFTWARE REQUIREMENTS 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the software requirements is to specify the 
functional, performance, and interface requirements for a 
software component. Requirements approach and tradeoff 
results are described. This section also specifies the 
major characteristics, implementation constraints, and 
design goals for software component. 

For the sake of traceability to the lowest level of 
implementation, each requirement shall be uniquely 
identified. A hierarchical or other classification scheme 
may be used to designate requirements that are allocated by 
groups to higher-level components and functions. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 REQUIREMENTS APPROACH AND TRADEOFFS 

Describe the overall approach in gathering, analyzing, and 
synthesizing requirements, including use of prototyping 
techniques. Explain the tradeoff process used to analyze 
conflicting requirements and arrive at the actual specifications 
for those requirements. Requirements trades and analysis 
information (such as a prototyping effort report) , especially 
that which must be reevaluated or considered when changes are 
proposed during development or maintenance, should be included in 
an appendix or explicitly referenced. 


4.0 EXTERNAL INTERFACE REQUIREMENTS 

The purpose of this section is similar to that of the traditional 
interface requirements document; that is, it contains the 
specification of requirements for interfaces between this 
software component and its external environment (i.e., all its 
users including both humans and other systems) . This section 
should be rolled-out when it is desirable to place it under 
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configuration control as a separate item. When rolled-out, it 
becomes the External Interface Requirements volume. 

Refer to the External Interface Requirements DID (SMAP-DID-P210) 
for a further description of the content for this section. 


5 . 0 REQUIREMENTS SPECIFICATION 


5.1 Process and Data Requirements 

Describe, as a separately numbered item for the sake of 
traceability, the process and data requirements for the software 
component in such terms as: 

1) Functions: 

o Input data and source 
o Transactions including algorithms 
o Output data and destination 

2 ) Data : 

o Definition 

o Relationships and structure 
o Protection requirements 
o Validity check requirements 
o Parameterization requirements 
o Format or implementation restrictions 


5.2 Performance and Quality Engineering Requirements 

Specify, as a separately numbered item for the sake of 
traceability, each performance requirement for the software 
component. Express the requirement in testable and quantitative 
terms. 

1) Address performance requirements such as: 

o Timing and sizing requirements 
o Sequence and timing of events, including user 
interaction tolerances 
o Throughput and capacity requirements 

2) Describe error detection, isolation, and recovery 
requirements for data and processes. 

3) Describe quality engineering requirements such as 
reliability, maintainability, or portability. 
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5 . 3 Safety Requirements 

Specify, as separately numbered items for the sake of 
traceability, the safety requirements for the software, 
including, m a prioritized list, the following: 

o Software hazard requirements which identify hazards 
and potential contributions to system mishaps 

o User interface considerations from a human factors 
engineering viewpoint, including information flow, 
processing analysis, estimates of potential operator/ 
maintainer processing capabilities, and analysis of 
critical tasks 


5.4 Security and Privacy Requirements 

Specify, as separately numbered items for the sake of 
traceability, the security and privacy requirements for the 
software, including access limitations to the system, such as 
existence of logon procedures and passwords, and of data 
protection and recovery methods. Express each requirement in 
testable and quantitative terms. Prioritize these requirements. 


5 . 5 Implementation Constraints 

Describe general implementation constraints on the design and 
implementation of the software, such as the use of government- 
furnished equipment (GFE) , commercial -off-the-shelf (COTS) , or 
use of specific compilers, etc. If existing software is required 
to be used or modified, include such requirements here. 

List or reference engineering and technical standards to be 
applied in the development of the software. 


5.6 Site Adaptation 

Specify requirements for adapting the component to the physical 
environments within which it operates, including site-specific 
adaptation data or special parameters that are defined during 
installation. Adaptation requirements may be presented in 
tabular form. 


62 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE REQUIREMENTS DID: SMAP-DID-P2 OO-SW 


5.7 Design Goals 

State design goals for the software in terms of: 

o Correctness to the degree that the implemented system is 
to satisfy its requirements 

o Reliability of the implemented system to consistently 
perform its intended function 

o Efficiency with which the implemented system is to use 
computer resources 

o Maintainability 

o Technology transparency 


6.0 TRACEABILITY TO PARENT'S DESIGN 

Describe how these requirements map to the requirements allocated 
from the parent. Use a table for presentation as an aid to 
clarity, and show both that requirements allocated from the 
parent have been taken into account and that requirements 
specified herein can be traced to the parent, or that there is a 
valid reason for introduction of any new requirements at this 
level. 


7.0 PARTITIONING FOR PHASED DELIVERY 

If the component is to be developed in several stages for phased 
delivery, identify the content for each delivery in terms of: 

1) Requirements and functions to be satisfied in the 
initial delivery. 

2) Additional requirements and functions to be satisfied 
for each successive delivery. 

Note that incremental development or phased delivery decisions at 
a higher (parent) level may impose phased delivery requirements 
upon this component. 
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8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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SMAP-DID-P200-HW 
HARDWARE REQUIREMENTS 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the hardware requirements is to specify the 
functional, performance, and interface requirements for a 
hardware component. Requirements approach and tradeoff 
results are described. This section also specifies the 
major characteristics, implementation constraints, and 
design goals for hardware component. 

For the sake of traceability to the lowest level of 
implementation, each requirement shall be uniquely 
identified. A hierarchical or other classification scheme 
may be used to designate requirements that are allocated by 
groups to higher— level components and functions. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 REQUIREMENTS APPROACH AND TRADEOFFS 

Describe the overall approach in gathering, analyzing, and 
synthesizing requirements, including use of prototyping 
techniques. Explain the tradeoff process used to analyze 
conflicting requirements and arrive at the actual specifications 
for those requirements. Requirements trades and analysis 
information (such as a prototyping effort report) , especially 
that which must be reevaluated or considered when changes are 
proposed during development or maintenance, should be included in 
an appendix or explicitly referenced. 


4.0 EXTERNAL INTERFACE REQUIREMENTS 

The purpose of this section is similar to that of the traditional 
interface requirements document; that is, it contains the 
specification of requirements for interfaces between this 
hardware component and its external environment (including all 
its users including both humans and other systems) . . This section 
should be rolled-out when it is desirable to place it under 
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configuration control as a separate item. When rolled-out, it 
becomes the external interface requirements volume . 

Refer to the External Interface Requirements DID ( SMAP-DI D-P2 1 0 ) 
for a further description of the content for this section. 


5 . 0 REQUIREMENTS SPECIFICATION 


5 . 1 Process Requirements 

Describe, as a separately numbered item for the sake of 
traceability, the process (functional) requirements for the 
hardware component in such terms as: 

o The purpose of the function 
o The operation performed 

o Inputs and outputs of the function along with their source 
and destination 
o Control of the function 
o Changes in modes or states 


5.2 Performance and Quality Engineering Requirements 

Specify, as a separately numbered item for the sake of 
traceability, each performance requirement for the hardware. 
Express the requirement in testable, quantitative terms, with 
appropriate tolerances and accuracy of measurement, and in order 
of priority. 

1) Address such operational requirements as: 

o Timing and sizing requirements 
o Capacity and operational frequency ranges 
o Response time ranges 

o Physical environment ranges (e.g., temperature, pressure) 
o Sequence and timing of events 
o Mean time between failure 

2) Specify fault tolerance and recovery requirements for the 
hardware in terms of: 

o Determination of when tolerable limits are exceeded 
o Recovery to normal operations from anomalous conditions 

3) Describe environmental characteristics affecting per- 
formance, including transportation, storage, and deployment 
of the system, such as: 

o Natural environment: heat, pressure, moisture, etc. 
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o Electromagnetic and other forms of radiation, including 
both those in the natural environment and those 
generated by the system 

o Magnetic environment 

o Hostile environment 

o Anticipated number of installations and their locations 

4) Quality Engineering Requirements such as: 

o Reliability 
o Maintainability 


5.3 Safety Requirements 

Specify, as separately numbered items for the sake of 
traceability, the safety and security requirements for the 
hardware. Express each requirement in testable and quantitative 
terms. Prioritize these requirements. 


5.4 Security and Privacy Requirements 

Specify, as separately numbered items for the sake of 
traceability, the security and privacy requirements for 
hardware. Express each requirement in testable and quantitative 
terms. Prioritize these requirements. 


5 . 5 Implementation Constraints 

Describe general implementation constraints as well as such 
specific constraints as physical environment and sizing. Include 
any constraints to utilize government- furnished equipment (GFE) 
or commercial-off-the-shelf (COTS) hardware. 

For example, describe any requirement to use or not to use 
existing hardware (whether the source is commercial, 
institutional, internal, or government- furnished ) . Also describe 
for each inheritable its source and technical requirements to 
acquire, integrate, and release the inheritable into the 
operational hardware environment. 

If the requirement is to use existing hardware, then describe the 
use of the hardware in terms of the functional requirements to be 
met. 

List or reference engineering and technical standards to be 
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applied in the development of the hardware. 


5.6 Site Adaptation 

Specify requirements for adapting the component to the physical 
environments within which it operates, including site-specific 
adaptation data such as site latitude and longitude, radar ranges 
and areas of coverage, and prescribed safety limits. Adaptation 
requirements may be presented in tabular form. 


5 . 7 Design Goals 

State design goals for the hardware in terms of: 

o Correctness to the degree that the implemented system is 
to satisfy its requirements 

o Reliability of the implemented system to consistently 
perform its intended function 

o Efficiency with which the implemented system is to use 
computer resources 

o Maintainability 

o Technology transparency 


6.0 TRACEABILITY TO PARENT* S DESIGN 

Describe how these requirements map to the requirements allocated 
from the parent. Use a table for presentation as an aid to 
clarity, and show both that requirements allocated from the 
parent have been taken into account and that requirements 
specified herein can be traced to the parent, or that there is a 
valid reason for introduction of any new requirements at this 
level . 


7.0 PARTITIONING FOR PHASED DELIVERY 

If the component is to be developed in several stages for phased 
delivery, identify the content for each delivery in terms of: 

1) Requirements and functions to be satisfied in the 
initial delivery. 

2) Additional requirements and functions to be satisfied 
for each successive delivery. 
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Note that incremental development or phased delivery decisions at 
a higher (parent) level may impose phased delivery requirements 
upon this component. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


70 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
OPERATIONAL PROCEDURES REQUIREMENTS: SMAP-DID-P2 0 O-OP 


SMAP-DID-P2 0 O-OP 

OPERATIONAL PROCEDURES REQUIREMENTS 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the operational procedures requirements is 
to specify the functional, performance, and interface 
requirements for a operational procedures component. 
Requirements approach and tradeoff results are described. 
This section also specifies the major characteristics, 
implementation constraints, and design goals for 
operational procedures component. 

For the sake of traceability to the lowest level of 
implementation, each requirement shall be uniquely 
identified. A hierarchical or other classification scheme 
may be used to designate requirements that are allocated by 
groups to higher-level components and functions. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P999 ) . 


3.0 REQUIREMENTS APPROACH AND TRADEOFFS 

Describe the overall approach in gathering, analyzing, and 
synthesizing requirements, including use of prototyping 
techniques. Explain the tradeoff process used to analyze 
conflicting requirements and arrive at the actual specifications 
for those requirements. Requirements trades and analysis 
information (such as a prototyping effort report) , especially 
that which must be reevaluated or considered when changes are 
proposed during development or maintenance, should be included m 
an appendix or explicitly referenced. 


72 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
OPERATIONAL PROCEDURES REQUIREMENTS: SMAP-DID-P200-OP 


4.0 EXTERNAL INTERFACE REQUIREMENTS 

The purpose of this section is similar to that of the traditional 
interface requirements document; that is, it contains the 
specification of requirements for interfaces between this 
operational procedures component and its external environment 
(i.e., all its users including both humans and other systems). 
This section should be rolled-out when it is desirable to place 
it under configuration control as a separate item. When 
rolled-out, it becomes the external interface requirements 
volume . 

Refer to the External Interface Requirements DID (SMAP-DID-P210) 
for a further description of the content for this section. 


5.0 OPERATIONAL PROCEDURES REQUIREMENTS 


5 . 1 Process Requirements 

Describe, as a separately numbered item for the sake of 
traceability, the process requirements for the operational 
procedures component in such terms as: 

o Control functions 
o Initiation activities 
o Monitoring and diagnostic functions 
o Recovery functions 
o Timing and sequence of activities 
o Emergency activities 


5 . 2 Safety Requirements 

Specify, as separately numbered items for the sake of 
traceability, the safety and security requirements for the 
operational procedures. Express each requirement in testable and 
quantitative terms. Prioritize these requirements . 


5.3 Security and Privacy Requirements 

Specify, as separately numbered items for the sake of 
traceability, the security and privacy requirements for the 
operational procedures. Express each requirement in testable and 
quantitative terms. Prioritize these requirements . 
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5 . 4 Implementation Constraints 

Specify any constraints on the design or implementation of this 
operational procedures component, including any engineering and 
technical standards to be applied in the development of the 
operational procedures. 


5.5 Design Goals 

When appropriate, describe design goals (in prioritized order) in 
terms of: 

o Correctness to the degree that the implemented component is 
to satisfy its requirements 

o Reliability of the implemented component to consistently 
perform its intended function 

o Efficiency with which the implemented component is to use 
operator resources 


6.0 TRACEABILITY TO PARENT'S DESIGN 

Describe how these requirements map to the requirements allocated 
from the parent. Use a table for presentation as an aid to 
clarity, and show both that requirements allocated from the 
parent have been taken into account and that requirements 
specified herein can be traced to the parent, or that there is a 
valid reason for introduction of any new requirements at this 
level . 


7.0 PARTITIONING FOR PHASED DELIVERY 

If the component is to be developed in several stages for phased 
delivery, identify the content for each delivery in terms of: 

1) Requirements and functions to be satisfied in the 
initial delivery. 

2) Additional requirements and functions to be satisfied 
for each successive delivery. 

Note that incremental development or phased delivery decisions at 
a higher (parent) level may impose phased delivery requirements 
upon this component. 
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8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the external interface requirements is to 
provide a single place where the interfaces between two 
different information systems, human users, or components 
may be stated. It may be desirable to roll-out this 
section into a volume for ease of configuration 
management . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 INTERFACES 

Identify and describe each interface with each class of user, 
including human users and other information systems. Each 
interface may represent a bi-directional flow of information. 

Use a graphic representation of the interfaces when appropriate 
for the sake of clarity. 

Specify the requirements governing each interface. Number or 
otherwise uniquely identify each requirement for the sake of 
traceability. Specify each requirement in testable, quantitative 
terms. Provide additional information about each requirement to 
aid in understanding its purpose and effect, and the goals for 
reliability, flexibility, etc. 

The requirement definition should address the following topics, 
as appropriate: 

o Purpose of the interface 

o Requirements for the interface, such as process, per- 
formance, safety, security, etc. 

o Implementation constraints on the interface 

o If applicable, traceability to parent* s design 
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4.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


5.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


6.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DI D-P9 9 9 ) 
for the detailed description of content for this section. 


7 . 0 APPENDICES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the information system design is to record 
the design information including design rationale and 
trades, the selected architecture of the information 
system, and the allocation of requirements to the 
subsystems or components. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design. Detailed design 
engineering and trades information that must be reevaluated or 
considered when changes are proposed during development or during 
sustaining engineering should be included in an appendix or 
explicitly referenced. 


4.0 EXTERNAL INTERFACES DESIGN 

The purpose of this section is similar to that of the traditional 
Interface Control Document (ICD) ; that is, it contains the design 
specifications for interfaces between the information system and 
its external users (human and other systems) . 

This section should be rolled—out when it is desirable to place 
it under configuration control as a separate item, such as when 
two systems are referencing the same interface design. When 
rolled-out, it becomes the external interface design volume. 

The primary interfaces to be designed are: 

o User Interfaces 
o Interface Allocation 
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Refer to the Information System External Interface Design DID 
(SMAP-DID-P311-SY) for a further description of the content for 
this section. 


5.0 ARCHITECTURAL DESIGN 

The purpose of the architectural design is to give a clear 
description of the top-level design of the information system. 
Identify and describe the structure of the information system in 
terms of its subsystems or its major software, hardware, and 
operational procedures components. Describe the internal 
interfaces between these subsystems or components. 

The design must address not only process and data requirements 
but also performance requirements, implementation constraints, 
site adaptation requirements, and design goals. 


6.0 REQUIREMENTS ALLOCATION AND TRACEABILITY 

The purpose of this section is to allocate the information 
system's requirements to the subsystems or major components 
identified in the preceding section. Use a table or other 
graphic if this aids the presentation. Ensure that all 
requirements are allocated, and that a complete set of 
requirements (including performance, site adaptation, etc.) for 
each subsystem or component is listed. 


7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT 

If the information system is to be developed incrementally (i.e., 
using the "build a little, test a little" approach with either a 
single delivery or as an interim process between deliveries) , 
identify the design elements to be included in each increment. 

Note that the design partitioning must conform to any phased 
delivery requirements for this or a higher level information 
system that are specified in the requirements section of this 
information system's product specification. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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INFORMATION SYSTEM DESIGN DID: SMAP-DID-P300-SY 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the operational procedures design is to 
describe the design approach and design for the development 
of the operational procedures. The actual operational 
procedures are documented in the Operational Procedures 
Manual . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design of the operational 
procedures. Detailed design engineering and trades information 
that must be reevaluated or considered when changes are proposed 
during development or during sustaining engineering should be 
included in an appendix or explicitly referenced. 


4 . 0 DESIGN DESCRIPTION 

Describe the classes of procedures in terms of: 

o System preparation and set-up procedures 
o Standard operating procedures 
o Fault and recovery procedures 
o Emergency procedures 

For each class of procedures define the associated set of 
scenarios for which procedures are to be developed. 
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5.0 EXTERNAL INTERFACE DESIGN 

Describe how the procedures are to relate to the hardware and 
software components of the information system. 

Describe interactions with users (human and other information 
systems and components) . 


6 . 0 REQUIREMENTS TRACEABILITY 

Show the traceability of all requirements including performance, 
safety, security, and constraints for this operational procedures 
component to the classes of procedures and scenarios identified 
in the design presented above. Explicitly identify any derived 
requirements and trace them to the individual scenarios. 


7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT 

If the operational procedures are to be produced using phased 
delivery or incremental development, specify here what 
requirements and functions are to be satisfied in each increment 
of the operational procedures. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P9 9 9 ) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the software architectural design is to 
record the logical/ functional design information for the 
software component. This includes design rationale and 
trades, the selected architecture of the component 
including at least one level of decomposition into software 
subcomponents or software design elements, the 
relationships and interface description between the 
subcomponents or design elements, and the allocation of the 
software component requirements to the subcomponents or 
design elements. 

If the decomposition is into subcomponents, then another 
layer of major software components and associated 
life-cycles and documentation is instantiated. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design of the software. Detailed 
design engineering and trades information that must be 
reevaluated or considered when changes are proposed during 
development or during sustaining engineering should be included 
in an appendix or explicitly referenced. 


4.0 ARCHITECTURAL DESIGN DESCRIPTION 

The purpose of this section is to describe the logical or 
functional design of the software component. The following 
topics should be included: 

o Logical or functional decomposition 
o Description of the subcomponents or design elements 
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O 

o 

o 

o 


including their inputs and outputs . 

Relationships and interactions between the subcomponents 

or design elements 

Logical data design - conceptual schema 
Entity/data identification and relationships 
Timing and sequencing 
Implementation constraints 


5.0 EXTERNAL INTERFACE DESIGN 

The purpose of this section is similar to that of the traditional 
Interface Control Document (ICD) ; that is, it contains the design 
specifications for interfaces between the software component and 
its external users (human and other systems or components) . 

This section should be rolled-out when it is desirable to place 
it under configuration control as a separate item, such as when 
two systems are referencing the same interface design. When 
rolled-out, it becomes the external interface design volume. 

The primary topics to be addressed are: 

o Interface design . . 

o Interface allocation to subcomponents or design elements 

Refer to the Software External Interface Design DID (SMAP-DID- 
P313.-SW) for a further description of the content for this 
section. 

6.0 REQUIREMENTS ALLOCATION AND TRACEABILITY 

This section documents the allocation of this software . 

component's requirements to the software subcomponents or design 

elements . 

Show the traceability of all requirements including performance 
and constraints for this software component to the design 
presented above. Explicitly identify any derived requirements. 


7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT 

If the software is to be produced using phased delivery or 
incremental development, specify here what requirement sand 
functions are to be satisfied in each increment of the software, 


88 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE ARCHITECTURAL DESIGN DID: SMAP-DID-P3 10-SW 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the hardware architectural design is to 
record the logical/ functional design information for the 
hardware component. This includes design rationale and 
trades, the selected architecture of the component 
including at least one level of decomposition into hardware 
subcomponents or hardware design elements, the connectivity 
and interface description between the subcomponents or 
design elements, and the allocation of the hardware 
component requirements to the subcomponents or design 
elements . 

If the decomposition is into subcomponents, then another 
layer of major hardware components and associated 
life-cycles and documentation is instantiated. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design of the hardware. Detailed 
design engineering and trades information that must be 
reevaluated or considered when changes are proposed during 
development or during sustaining engineering should be included 
in an appendix or explicitly referenced. 


4.0 ARCHITECTURAL DESIGN DESCRIPTION 

The purpose of this section is to describe the logical or 
functional design of the hardware component. The following 
topics should be included: 

o Logical/ functional decomposition 

o Description of the subcomponents or design elements 
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including their inputs and outputs 
o Relationships and interactions between the sub 
components or design elements 
o Timing and sequencing 
o Implementation constraints 


5.0 EXTERNAL INTERFACE DESIGN 

The purpose of this section is similar to that of the traditional 
Interface Control Document (ICD) ; that is, it contains the design 
specifications for interfaces between the hardware component and 
its external users (human and other systems or components) . 

This section should be rolled-out when it is desirable to place 
it under configuration control as a separate item, such as when 
two systems are referencing the same interface design. When 
rolled-out, it becomes the external interface design volume. 

The primary topics to be addressed are: 

o Interface Design 

o Interface Allocation to subcomponents or design elements 

Refer to the Hardware External Interface Design DID (SMAP-DID- 
P311-HW) for a further description of the content for this 
section. 


6.0 REQUIREMENTS ALLOCATION AND TRACEABILITY 

This section documents the allocation of this hardware 
component's requirements to the hardware subcomponents or design 
elements. 

Show the traceability of all requirements including performance 
and constraints for this hardware component to the design 
presented above. Explicitly identify any derived requirements. 


7.0 PARTITIONING FOR INCREMENTAL DEVELOPMENT 

If the hardware is to be produced using phased delivery or 
incremental development, specify here what requirements and 
functions are to be satisfied in each increment of the hardware. 
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8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the information system external interface 
design is to record the interface specifications between 
the information system and a user (human or another 
information system or component) . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 USER INTERFACES DESIGN 

Describe the design for each interface identified in the 
requirements section of the Product Specification as an external 
user interface in terms of: 

1) Traceability to the external interface requirements. 

2) Information to be passed over the interface in such terms 
as: 

o Information description 
o Initiation criteria 
o Expected response 

o Item usage (control, data, message) 
o Data attributes and format 
o Conventions 
o Protocol 

o Error handling and recovery 
o Queuing 

o Electrical and mechanical characteristics 
o Timing and Sequencing 
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4 . 0 INTERFACE ALLOCATION 

The purpose of this section is to allocate the information 
system's external interface requirements to the appropriate 
subsystems or components. Use a table or other graphic aid if 
this aids the presentation. Ensure that all external interface 
requirements, including performance, site adaptation, and design 
goals, are allocated. 


5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


6.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the software external interface design is to 
record the logical and functional interface specifications 
between the software component and a user (human or another 
information system or component) . 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P9 99) . 


3.0 INTERFACE DESIGN 

Describe the design for each interface identified in the 
requirements section of the Software Product Specification as an 
external interface in terms of: 

o Information description 
o Initiation criteria 
o Expected response 
o Protocol and conventions 

o Error identification, handling, and recovery 
o Queuing 

o Implementation constraints 


4 . 0 INTERFACE ALLOCATION 

The purpose of this section is to allocate the softwares 
external interface requirements to the appropriate subcomponents 
or design elements. Use a table or other graphic aid if this 
aids the presentation. Ensure that all external interface 
requirements, including performance, site adaptation, and design 
goals, are allocated. 
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5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


6.0 GLOSSARY 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 APPENDICES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the hardware external interface design is to 
record the logical/ functional interface specifications 
between the hardware component and a user (human or another 
information system or component) . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P9 99) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 INTERFACE DESIGN 

Describe the design for each interface identified in the 
requirements section of the Hardware Product Specification as an 
external interface in terms of: 

o Information description 
o Initiation criteria 
o Expected response 

o Item usage (control, data, message) 
o Data attributes and format 
o Conventions 
o Protocol 

o Error handling and recovery 
o Queuing 

o Timing and sequencing 
o Implementation constraints 


4 . 0 INTERFACE ALLOCATION 

The purpose of this section is to allocate the hardware* s 
external interface requirements to the appropriate subcomponents 
or design elements. Use a table or other graphic aid if this 
aids the presentation. Ensure that all external interface 
requirements, including performance, site adaptation, and design 
goals, are allocated. 
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5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


6.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the software detailed design is to record 
the design information for the software component . This 
includes design rationale and trade-offs, the selected 
design of the component including its decomposition into 
compilation and code units, the design of all interfaces, 
and the mapping between the logical or functional design 
(i.e., design elements) of the software component and its 
detailed design units. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P999 ) . 


3.0 DETAILED DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design of the software. Detailed 
design engineering and trades information that must be 
reevaluated or considered when changes are proposed during 
development or during sustaining engineering should be included 
in an appendix or explicitly referenced. 


4.0 DETAILED DESIGN DESCRIPTION 

4.1 Compilation Unit Design and Traceability to Architectural 
Design 

This section presents the overall physical design of the software 
component into its compilation units. The information typically 
includes : 

o Compilation unit identification 

o Compilation unit descriptions including: 

- inputs and outputs 


104 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE DETAILED DESIGN DID: SMAP-DID-P320-SW 


functions (based on design elements) 

- data descriptions and relationships 

- diagrams 

- control and signal flow 

- error handling 

o Interfaces descriptions between compilation units 

o Packaging details such as placement of units in library 

This section includes a mapping of (or the traceability between) 
the architectural design elements to the compilation units. 


4.2 Detailed Design of Compilation Units 

This section contains the design information detailed to the 
level necessary to code the individual compilation units and all 
lower level code units. The information for each unit should 
include: 

o Detailed design to the lowest level (i.e., module or sub- 
routine) 

o Functions or operations 
o Algorithms 

o Specific data definitions including data conversions 
o Local and global data 

o Parameters for initiation and adaptation 

o Logic flow, including: 

- control flow 

- timing variations 

- priority assignments 

- interrupt priorities and handling 

o Error detection and handling 

o Physical data design: 

- internal schema 

- query language 

- access method 

- key, record, and data element definition and structure 

- use of database management capability 

o Device interface 
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5.0 EXTERNAL INTERFACE DETAILED DESIGN 

The purpose of this section is similar to that of the traditional 
Interface Control Document (ICD) ? that is, it contains the 
detailed design specifications for interfaces between the 
software component and its external users (human, other systems, 
and components) . 

This section should be rolled-out when it is desirable to place 
it under configuration control as a separate item, such as when 
two components are referencing the same interface design. When 
rolled-out, it becomes the External Interface Detailed Design 
volume . 

Refer to the Software External Interface Detailed Design DID 
(SMAP-DID-P321-SW) for a further description of the content for 
this section. 


6.0 CODING AND IMPLEMENTATION NOTES 

The purpose of this section is to specify information such as. 

o Stubs for incremental development 
o Use of compiler options 


7.0 FIRMWARE SUPPORT MANUAL 

If the software design is implemented in firmware, refer to the 
Firmware Support Manual DID ( SMAP-DID-P3 2 2 -SW) for a further 
description of the content of this section. 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the hardware detailed design is to record 
the physical design information for the hardware 
component. This includes physical design rationale and 
trades, the selected physical design of the component 
including its decomposition into assemblies and line 
replaceable units, the design of all physical interfaces, 
and the mapping between the logical/ functional design 
(i.e. design elements) of the hardware component and its 
physical design. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 DETAILED DESIGN APPROACH AND TRADEOFFS 

Describe the rationale and tradeoffs, and other design 
considerations, including any use of prototyping, influencing the 
major decisions affecting the design of the hardware. Detailed 
design engineering and trades information that must be 
reevaluated or considered when changes are proposed during 
development or during sustaining engineering should be included 
in an appendix or explicitly referenced. 


4.0 DETAILED DESIGN DESCRIPTION 


4.1 Assembly Design and Traceability to Architectural Design 

This section presents the overall physical design of the hardware 
component into its assemblies. The information typically 
includes: 

o Assembly identification 

o Assembly descriptions including: 

- inputs and outputs 
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- functions (based on design elements) 

- diagrams 

- control and signal flow 

- error handling 

o Interfaces descriptions between assemblies including 

- interrupts and signals 

- mechanical and electronic connections 

o Overall packaging description 

This section includes a mapping (or the traceability) between 
architectural design elements into the assemblies. 


4.2 Detailed Design of Assemblies 

This section contains the design information detailed to the 
level necessary to fabricate the individual assemblies and their 
physical units (such as line replaceable units) . The information 
for each assembly should include: 

o Detailed design to the single fabrication unit level 
(such as a chip) 

o Functions or operations for each unit 
o Ports and connectors 
o Schematic diagrams 
o Logic flow including 

- timing variations 

- priority assignments 

o Error detection and handling 
o Wiring diagrams 

o Packaging design and construction 
o Environmental fabrication constraints 


5.0 EXTERNAL INTERFACE DETAILED DESIGN 

The purpose of this section is similar to that of the traditional 
Interface Control Document (ICD) ; that is, it contains the 
detailed design for interfaces between the hardware component and 
its external users (human and other systems and components) . 

This section should be rolled-out when it is desirable to place 
it under configuration control as a separate item, such as when 
two systems are referencing the same interface design. When 
rolled-out, it becomes the external interface detailed design - 
volume. 

Refer to the Hardware External Interface Detailed Design DID 
(SMAP-DID-P321-HW) for a further description of the content for 
this section. 
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6.0 FABRICATION NOTES 

The purpose of this section is to record information about the 
fabrication of the hardware component. This section could 
contain information such as: 

o Special fabrication instruments or constraints 
o Parts list 


7.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the software external interface detailed 
design is to record the physical design information for the 
external interfaces to the software component. This 
includes the data types, physical data format or layout, 
message descriptions, data transmissions, and protocols and 
priorities . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P99 9 ) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 INTERFACE ALLOCATION DESIGN 

This section describes the mapping (or the traceability) of the 
external interface design of the software component into its 
specific compilation units and lower level units. 


4.0 PHYSICAL INTERFACE DESIGN 

Describe each external interface for the software component, or 
each interface, describe the details of the interface, including: 

a) (Interface Name/ Identifier) Type and Purpose. Describe the 
type and purpose of the interface. 

b) Data Transmission. Provide a detailed specification of the 
data records and elements transmitted across the interface 
in such terms as: 

o Unique identifier for each record and data element 
o Brief description and purpose of each record and data 
element 

o Source and destination components for each record or 
single data element transmission 
o Data type and (if appropriate) unit of measure 
o Limit and range of values 
o Accuracy 
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o Precision (in terms of significant digits) 

If shared memory is used, then define: 
o The purpose for the shared memory 

o The shared memory location (s)s used for transmissions 
across the interface 

c) Message Descriptions. Identify each message transmitted 
across the interface and specify the assignment of data 
elements to each message. Provide cross references between 
data elements and messages, as a two-way sorted list. 

d) Interface Priority. Specify the relative priority of this 
interface and of each message transmitted across it. 

e) Communication Protocols. Identify the protocol for the 
interface by name and describe its technical details in 
terms of the following: 

o Fragmentation and reassembly of messages 
o Message formatting 

o Error control and recovery procedures, including fault 
tolerance features 

o Synchronization, including connection establishment, 
maintenance, termination, and timing 

o Flow control, including sequencing, and buffer allocation 

o Data transfer rate, whether periodic or aperiodic, and 
minimum interval between transfers 

o Routing, addressing, and naming conventions 

o Transmission services, including priority and grade 

o Status, identification, notification, and other 
reporting features 

o Security, including encryption, user authentication, 
compartmentalization, and auditing 
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5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


6 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the hardware external interface detailed 
design is to record the physical design information for the 
external interfaces to the hardware component. This 
includes the physical wiring, ports and connectors, and 
timing and protocol definitions. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DI D-P9 9 9 ) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 INTERFACE ALLOCATION DESIGN 

This section describes the mapping (or traceability) of the 
external interface design of the hardware component into its 
specific assemblies and units. 


4.0 PHYSICAL INTERFACE DESIGN 

This section contains the physical design information detailed to 
the level necessary to ensure the proper function of the physical 
interfaces of the physical units of the hardware component (such 
as line replaceable units) . The information should include: 

o Ports and connectors 
o Schematic diagrams 

o External signals and interrupts including 

- protocols 

- timing variations 

- priority assignments 

o Error detection and handling 
o Wiring diagrams 

o Environmental fabrication constraints 
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5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


6 . 0 GLOSSARY 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

8 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the firmware support manual is to provide an 
instruction and reference manual for the firmware . 
programmer to program, support, maintain, and monitor 
firmware that is a part of the software component. 

The firmware support manual provides the information 
necessary to program the read-only memory (ROM) devices, 
programmable ROMs (PROMs) , and erasable PROMs (EPROMs) . 

The firmware support manual describes the ROM devices and 
support software and equipment required for reprogramming. 

The firmware support manual does not provide information 
regarding the design and implementation (bit pattern) 
within the device. That infomation is contained in the 
software detailed design section. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 DEVICES 

List the firmware devices and provide the following information 
for each. 


3 . 1 Physical Description 

Provide a complete physical description of ROM components, 
including as a minimum: 

1) Memory size (length and width in bits) . 

2) Pin functional descriptions. 

3) Operating characteristics such as access time, power 
supply/requirements, logic levels. 
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4) Logical interfaces (e.g., addressing scheme, chip 
selection, etc.). 

5) Available (unused) portion. 

6) Internal and external identification scheme. 

7) Manufacturer's part number. 

8) Timing characteristics (include diagram if appropriate) . 


3.2 Installation and Replacement 

Describe all installation, removal, and replacement procedures 
for the ROM device. Describe the device addressing scheme and 
its implementation. If appropriate, use a diagram to describe 
the board layout and which includes a socket number and pin 
identification for the device. 


3 . 3 Limitations 

Describe the operational and environmental limits to which the 
ROM device may be subjected and still maintain satisfactory 
operation. 


4 . 0 PROGRAMMING TOOLS 

The purpose of this section is to describe the hardware and 
software tools and procedures for programming the device. 


4 . 1 Equipment 

Describe the equipment used for programming the ROM device, 
including general purpose peripherals and special equipment used 
for device loading, test, and verification. 

Identify each piece of equipment by: 

o Manufacturer's name and designation, 
o Major functional purpose of the equipment, 
o Any unique features. 
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4 . 2 Software 

Describe the computer software used for programming the ROM 
device, including utilities, for device loading, bum- in, and 
test. 

Identify each software item by: 

o Vendor and vendor's designation, including version 
number 

o Major function in terms of purpose 
o Any unique features 


4 . 3 Programming Procedures 

Describe the procedures used for ROM programming, including: 

o Logic data generation 
o Device loading 

o Reliability aging conditions and schedules 
o Test 

o Verification 


5 . 0 SECURITY IMPLICATIONS 

Describe any special handling or security requirements for the 
devices or support hardware and software. 


6.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999 ) 
for the detailed description of content for this section. 


122 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
(SOFTWARE) FIRMWARE SUPPORT MANUAL DID: SMAP-DID-P3 2 2 -SW 


8 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the version description is to provide a 
precise description of the particular version of the 
information system or component being released. This 
description includes: 

o Version of requirements applicable to this version 
o Version of design applicable to this version 
o Exact description of the product contents in this version 

For paper products, the product itself may also be included 
within the version description section, if appropriate. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3 . 0 PRODUCT DESCRIPTION 

By reference to the appropriate sections of the requirements or 
design sections of the product specification, give a description 
of this version of the product. 


4.0 INVENTORY AND PRODUCT 


4 . 1 Materials Released 

This section lists physical materials delivered with the version: 

1) All media containing code (tapes, disks) that constitute 
the version and specific formats. 

2) All operation and support documents. 

3) All utility and support software and equipment that is not 

a part of the version but that is required to load, operate, 
or maintain this version. 
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4) All required hardware. 


4 . 2 Product Content 

Identify the exact configuration of the product delivered by this 
version. Paper products may be included here in-line or 
rolled-out into a separate volume. For non-paper products or 
rolled-out volumes, include a pointer to the product (e.g., model 
and serial numbers, or a document citation) . 

For software, indicate the location of the source and object code 
for this version. Printed listings may be included as an 
appendix to this document. Executables will normally be included 
on the tapes (or other medium) listed in the preceding section. 
Specify here the compiler and, if applicable, the assembler, and 
version of each, used to generate the executable from the source 
code. 

For hardware, indicate the location of the detailed design 
drawings, part listings, hardware model and serial numbers, and 
other information that precisely identifies the hardware. The 
data for hardware identification can be recorded in a manner 
similar to that used for software. 

For operational procedures, the exact configuration is the 
operational procedures manual (refer to SMAP-DIDP4 10-OP) . Hence, 
the version number of that manual is an essential part of the 
version description. In most cases these procedures are 
rolled-out into a separate volume for ease of use. 

When appropriate, the product description statement will include 
version descriptions for subsystems, components, etc. , to the 
lowest configuration management unit. For example, for a major 
software component, it is a statement of the version descriptions 
of all of the software compilation units. For an information 
system, it is a statement of the version descriptions for all of 
the next level decomposition items that may be subsystems, or the 
hardware, software, and operational procedures components. 


5 . 0 CHANGE STATUS 

Describe the capabilities newly installed in this version. 
Identify the associated approved change, if applicable. Identify 
any requirements that are known to be unsupported. 

Also identify any changes in capabilities provided by the 
previous version, if applicable. 

Indicate any interfaces to other components affected by the 
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changes installed in this version, and describe the impacts. The 
following sections identify changes applicable to this version 
(but not to previous versions) and their status. 


5 . 1 Installed Changes 

List, by identifier and title, the changes approved by a 
configuration control authority or board that have been newly 
incorporated in this version. Identify any change reports 
(Engineering Change Proposal, Change Requests, Document Change 
Notice, etc.) associated with each change. 


5 . 2 Waivers 

List all waivers that have been approved for this version and 
summarize their effects on the version's functional capabilities 
or operation. 


5 . 3 Possible Problems and Known Errors 

Identify and describe the operational effects of each possible 
problem and known error in the version, together with steps being 
taken to resolve them and ways for working around them. 


6.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P9 99) 
for the detailed description of content for this section. 

7 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

8 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

9 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the operational procedures manual is to 
document the actual operational procedures of an 
information system. This is the product of the operational 
procedures component of an information system. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 SYSTEM PREPARATION AND SET-UP PROCEDURES 

This section describes the procedures conducted by the operator 
to set-up and prepare the system for operation, both initially 
and for new releases or modifications to the system. 

If instructions provided by the hardware and software components 
are to be executed, then reference (rather than duplicate) those 
instructions. Procedures for operators which augment those 
instructions should be documented here. 


4.0 STANDARD OPERATING PROCEDURES 

This section describes the detailed operational procedures that 
are part of the standard practices for operating the information 
system. The types of procedures defined here include: 

o Monitoring procedures 

o Daily operating procedures, such as system back-ups and 
logs for maintenance 

o Standard safety and security procedures 

o On-demand procedures, such as in response to a user request 

If the operator is using a hardware or software feature 
(documented in the appropriate user's guide), then whenever 
possible reference, rather than duplicate, those instructions. 
Procedures for operators which augment those instructions should 
be documented here. 
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5.0 FAULT AND RECOVERY PROCEDURES 

This section describes the detailed operational procedures to be 
conducted in case of a fault or abnormal condition in the 
hardware, software, or some other aspect of the system. The 
immediate actions and subsequent recovery procedures are 
documented for every anticipated fault condition. 


6 . 0 EMERGENCY PROCEDURES 

This section describes the detailed operational procedures to be 
conducted in case of an emergency. The types of procedures 
defined here include: 

o Procedures for critical system failures 

o Environmental emergency procedures, such as fires or hur- 
ricanes 

o Safety or security emergency procedures 


7 . 0 DIAGNOSTIC PROCEDURES 

Explain diagnostic procedures the operator may employ such as: 

o Correlation to error messages 
o Diagnostic initialization 
o Recording diagnostic data 
o Analysis of diagnostic results 


8.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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10.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

11.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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SMAP-DID-P500 
USER'S GUIDE 
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EXPLANATORY NOTE 

The purpose of the user’s guide is to provide end users 
(rattier than system operators or administrators) with 
instructions explaining how to execute the system or 
component (software, hardware) effectively. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 OVERVIEW OF PURPOSE AND FUNCTIONS 

Describe the purpose and main capabilities of the system or 
component, and state its overall operation in terms of: 

o Functions 
o Options 

o Restrictions and limitations 
If appropriate, reference the version description section. 


4.0 INSTALLATION AND INITIALIZATION 

Explain in detail the procedures for installing, tailoring, and 
initiating the system or component, including: 

o Equipment set-up 
o Power-on and power-off 
o Bootstrap and load 
o Initiation commands 
o Interrupt / recovery/ restart 

o Initialization of files, variables, or other data 
o Tailoring, reconfiguration, adaptation 
o Re- initialization after failure 
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5.0 STARTUP AND TERMINATION 

Describe how to start and terminate operation normally, and how 
to determine whether normal termination has occurred. 

If the user has some control over abnormal termination, describe 
the procedures involved such as: 

o Trouble indicators and corrective actions 
o On-line interventions 
o Trap recovery 
o Operating communications 
o Fault isolation techniques 

o Conditions requiring software abort or equipment 
shut-down 

Describe procedures for restarting after both normal and abnormal 
termination. If recovery procedures are required for restarting 
after abnormal termination, explain them in terms of: 

o Check points 
o Collection of failure data 
o Restoring files 

o Restoring devices to operational mode 


6.0 FUNCTIONS AND THEIR OPERATION 
Describe each function in terms of: 
o Purpose of function 

o Step-by-step procedures for execution 
o User inputs: commands, data, and option selection 

*> Expected results and the procedures for examining these 
results 

Related functions 

Desc any inputs from a source other than the user that may 
occui e the system or component is in use and that may affect 
its in fc face with the user? for example, inputs from a remote 
sensor. Include applicable attributes of the input such as 
format, frequency, effect upon the system or component state or 
mode. 
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7.0 ERROR AND WARNING MESSAGES 

List and explain each possible error condition and associated 
message that may be encountered. Describe the corresponding 
corrective actions to be taken. 

If appropriate, identify an agency that may be called upon for 
assistance. 


8 . 0 RECOVERY STEPS 

Explain recovery procedures the user may employ. 

9.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

10.0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

11.0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 

12 . 0 APPENDICES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 9 9 ) 
for the detailed description of content for this section. 
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SMAP-DID-P600-SY 

INFORMATION SYSTEM MAINTENANCE MANUAL 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the information system maintenance manual is 
to provide a repository of data and information to aid in 
analyzing and debugging the information system. The 
information system maintenance manual contains maintenance 
information on each component or subsystem of the 
information system (either directly or by reference) and 
any additional system considerations. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 PROBLEM DETECTION AND FAULT ISOLATION 

Address first the overall information system, then subsystems and 
components (directly or by reference) . 

Discuss the problem detection, fault isolation, and reporting for 
the information system. Continue this discussion to the 
subsystem and component level (directly or by reference) . 

Describe the course of action taken for each type of problem. 

This description should include a statement of the methods 
employed in problem detection. Discuss problem detection and 
resolution in terms of the environment in which the information 
system is placed. Describe any safety, security, or privacy 
constraints that must be imposed on maintenance procedures. 

This section includes a description of the built-in test 
diagnostics including: 

o Function and operation 
o Normal results 

o Abnormal conditions and probable fault diagnostics 
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4 . 0 PREVENTATIVE MAINTENANCE 

The purpose of this section is to describe the preventative 
maintenance procedures that are to be used on this information 
system. Continue this discussion to the subsystem or component 
level. Topics typically include: 

o Maintenance procedures 

o Test descriptions including the use of built-m tests 
o Frequency of maintenance 

5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


6 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID ( SMAP-DID-P9 9 9 ) 
for the detailed description of content for this section. 

8 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


138 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE MAINTENANCE MANUAL DID: SMAP-DID-P600-SW 

SMAP-DID-P600-SW 
SOFTWARE MAINTENANCE MANUAL 
DATA ITEM DESCRIPTION 

TABLE OF CONTENTS 

Section 

1.0 INTRODUCTION 

2 . 0 RELATED DOCUMENTATION 

3 . 0 IMPLEMENTATION DETAILS 

4.0 MODIFICATION AIDS 

5.0 CODE ADAPTATION 

6.0 ABBREVIATIONS AND ACRONYMS 

7 . 0 GLOSSARY 

8 . 0 NOTES 

9 . 0 APPENDICES 


Release 4.3, 2/28/89 


139 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE MAINTENANCE MANUAL DID: SMAP-DID-P600-SW 


EXPLANATORY NOTE 

The purpose of the software maintenance manual is to 
provide a repository of data and information to aid in 
analyzing and debugging a software component and its lower 
level software units. This should not duplicate 
information available in other sections of the software 
product specification. 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID ( SMAP-DID-P9 99) . 


3 . 0 IMPLEMENTATION DETAILS 

Describe details about: 

o Specific data representations or formats 
o Operating system interfaces and dependencies 
o Support software such as libraries 
o Hardware dependencies 
o Other interfaces 


4 . 0 MODIFICATION AIDS 

Describe design details that could be used in the modification or 
expansion of the software component. 


5 . 0 CODE ADAPTATION 

Describe design details that support the initialization or 
adaptation of data or code. Relate this information to version 
information of the software component. 


140 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
SOFTWARE MAINTENANCE MANUAL DID: SMAP-DID-P600-SW 


6.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


7 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


9 . 0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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EXPLANATORY NOTE 

The purpose of the hardware maintenance manual is to provide 
a repository of data and information that is to aid in 
analyzing and debugging hardware components to at least the 
line replaceable unit level. When information relevant to 
hardware maintenance has been previously placed in another 
part of the hardware product specification, a reference to 
that information should be given. 


1 . 0 INTRODUCTION 

The outline and content description to be used when preparing this 
section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing this 
section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 PROBLEM DETECTION AND FAULT ISOLATION 

Discuss the problem detection, fault isolation, and reporting to 
at least the line replaceable unit level for each assembly of the 
hardware component. Describe the course of action taken for each 
type of problem. This description should include a statement of 
the methods employed in problem detection. Discuss problem 
detection and resolution in terms of the environment in which the 
hardware component is placed. Describe any safety, security, or 
privacy constraints that must be imposed on maintenance 
procedures . 

This section includes a description of the built-in test 
diagnostics including: 

o Function and operation 
o Normal results 

o Abnormal conditions and probable fault diagnostics 
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4 . 0 PREVENTATIVE MAINTENANCE 

The purpose of this section is to describe the preventative 
maintenance procedures that are to be used on this hardware 
component. Topics typically include: 

o Maintenance procedures 

o Test descriptions including the use of built-in tests 
o Frequency of maintenance 


5.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID ( SMAP-DID-P99 9 ) 
for the detailed description of content for this section. 


6 . 0 GLOSSARY 

Refer to the Product Specification Template DID ( SMAP-DID-P999 ) 
for the detailed description of content for this section. 


7 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


8 . 0 APPENDICES 

Refer to the Product Specification Template DID ( SMAP-DID-P99 9 ) 
for the detailed description of content for this section. 
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SMAP-DI D-P9 2 0 
STANDARDS AND GUIDELINES 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the standards and guidelines is to document 
new standards that have been developed per direction in the 
management plan. In general, these standards refer to a 
convention that has been developed for use across a number 
of systems or components. This DID is not intended to be 
used to document the design of an interface between two 
systems or components. 

The selection and use of standards is described in the 
appropriate management plan(s) . 


1.0 INTRODUCTION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


2 . 0 RELATED DOCUMENTATION 

The outline and content description to be used when preparing 
this section is described in detail in the Product Specification 
Template DID (SMAP-DID-P999) . 


3.0 OVERVIEW OF STANDARD 


3 . 1 Scope of Standard 

Describe the scope and boundaries for which the standard is 
applicable. The scope is usually expressed in organizational 
terms. 


3.2 Rationale for Standard 

Explain the reasons and objectives for the standard. Include any 
background information necessary for understanding the 
rationale . 


146 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
STANDARDS AND GUIDELINES DID: SMAP-DI D-P9 2 0 


3.3 Interface with Other Standards 

Explain the relationship between this standard and other 
standards with which there is an interface or potential for 
overlap. 


4 . 0 <THE STANDARD> 

Specify the standard in simple, clear, and operational terms. 
Follow the statement of the standard with an explanation of the 
rules to be followed in its application. 


5.0 APPLICATION AND SUPPORT OF <THE STANDARD> 


5.1 Guidelines for Use of <the Standard> 

Explain how the standard is to be applied in various situations. 


5.2 Tools Supporting the Application and Use of <the Standard> 

Describe any tools, such as an engineering support environment, 
that support application and use of the standard. 

6.0 ASSURANCE AND ENFORCEMENT OF <THE STANDARD> 

Describe by whom the standard will be assured and enforced, using 
what methods, and at which points in the life-cycle. 


7.0 ABBREVIATIONS AND ACRONYMS 

Refer to the Product Specification Template DID (SMAP-DI D-P9 99) 
for the detailed description of content for this section. 

8 . 0 GLOSSARY 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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9 . 0 NOTES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 


10.0 APPENDICES 

Refer to the Product Specification Template DID (SMAP-DID-P999) 
for the detailed description of content for this section. 
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SMAP-DID-P999 

PRODUCT SPECIFICATION TEMPLATE 
DATA ITEM DESCRIPTION 
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EXPLANATORY NOTE 

The purpose of the template is to describe the set of 
common sections that are to appear in the document 
specified by this documentation standard and in any 
rolled-out volumes. When using this template for the 
document itself, rather than for a rolled-out volume, 
substitute "Document” for "Volume" in the following. 


1.0 INTRODUCTION 


1.1 Identification of Volume 

Identify this physical volume in terms of its relationship to the 
parent document (s) in the documentation set for this information 
system or component. For documentation set documents, identify 
the parent (s) in the decomposition tree for the information 
system. For example: 

"This is the Software Product Specification for the XYZ 
Information System." 

"This is the Concept Volume of the Product Specification for 
the XYZ Information System." 

"This is the External Interfaces Volume of the Detailed Design 
volume of the Hardware Product Specification for the XYZ 
Information System." 


1.2 Scope of Volume 

Describe the area of cognizance, responsibility, and 
applicability for this volume. 


1.3 Purpose and Objectives of Volume 

Describe the purpose and objectives for this volume concisely and 
in specific terms. 
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1.4 Volume Status and Schedule 

Describe the status, including goals and dates, for production or 
revision of the volume. Documentation is often generated 
incrementally or iteratively. If this is the case for this 
volume, also summarize here the planned updates and their release 
dates . 


1.5 Volume Organization and Roll-Out 

Briefly describe what is presented in each major section within 
this version of the volume and what is in each appendix. 

If any sections are rolled-out into subordinate volumes of this 
volume, then cite those volumes and provide a documentation tree 
pointing to the subordinate volumes and relating them to the 
parent . 


2 . 0 RELATED DOCUMENTATION 

The purpose of this section is to provide the references or 
bibliography for this volume. 

Cite documents by short or common title (if any) , full title, 
version or release designator (if appropriate) , date, publisher 
or source, and document number or other unique identifier. 


2 . 1 Parent Documents 

Begin this section as follows, depending upon whether this is a 
volume of a document or the document itself: 

"The following document (s) is (are) parent to this volume:" 

or: 

"The following document (s) is (are) the parent from which this 
documents scope and content derive:" 

If this is a document, cite the appropriate document at the next 
higher level. For example, an Information System Management Plan 
would cite the management plan for the next higher level 
information system, or the Software Product Specification would 
cite the Software Management Plan and the parent* s product 
specification. If there is no higher level, state "None." here. 

If this is a volume rolled-out from a document, cite that 
document. If this is a volume rolled-out from another volume, 
cite each volume in the hierarchical path back to the parent 
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document, starting with the volume immediately superior to this 
one. 


2.2 Applicable Documents 

Begin this section as follows: 

"The following documents are referenced herein and are 
directly applicable to this volume:" 

Provide the citations for every document (other than the parent) 
referenced within this volume, or which are directly applicable, 
or contain policies or other directive matters that are binding 
upon the content of this volume. 


2 . 3 Information Documents 

Begin this section as follows: 

"The following documents, although not directly applicable, 
amplify or clarify the information presented in this 
volume, and are not binding:" 

or, use an appropriate introduction to indicate the relationship 
of the documents listed here to this volume. 


3.0 - N.O CONTENT FOR ROLLED-OUT SECTION 

Each major subsection of the section of an information system or 
component product specification, or of a volume thereof, being 
rolled-out into a separate subordinate volume becomes a major 
section in the rolled-out volume. 


N+1.0 ABBREVIATIONS AND ACRONYMS 

This section follows the sections containing the content for the 
rolled-out section. 

The abbreviations and acronyms section contains an alphabetized 
list of the definitions for abbreviations and acronyms used in 
this volume. 


N+2 . 0 GLOSSARY 

The glossary contains an alphabetized list of definitions for 
special terms used in the volume ? i . e . , terms used in a sense 
that differs from or is more specific than the common usage for 
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such terms. 


N+3.0 NOTES 

Use this section to present information that aids in 
understanding the information provided in previous sections, and 
which is not contractually binding. 


N+4 . 0 APPENDICES 

The appendices contain material that is too bulky, detailed, or 
sensitive to be placed in the main body of text. Refer to each 
appendix in the main body of the text where the information 
applies. Appendices may be bound separately, but are considered 
to be part of the volume and shall be placed under configuration 
control as such. 
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8.0 ABBREVIATIONS AND ACRONYMS 

AR - Acceptance Review 

CDR - Critical Design Review 

COTS - Commercial off-the-shelf 

DID - Data Item Description 

DoD - Department of Defense 

DRL - Data Requirements List 

ECP - Engineering Change Proposal 

EPROM - Erasable Programmable Read-Only Memory 

FCA - Functional Configuration Audit 

FMEA - Failure Modes and Effects Analysis 

GFE - Government- furnished equipment 

IV&V - Independent Verification and Validation 

LRU - Line (or Lowest) Replaceable Unit 

MTBF - Mean Time Between Failures 

MTTR - Mean Time to Repair 

NASA - National Aeronautics and Space Administration 
NHB - NASA Handbook 

NRCA - Nonconformance Reporting and Corrective Action 

PCA - Physical Configuration Audit 

PDR - Preliminary Design Review 

PROM - Programmable Read-Only Memory 

RFP - Request for Proposal 

RID - Review Item Discrepancy 

ROM - Read-Only Memory 

RR - Requirements Review 
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SMAP - Software Management and Assurance Program 
SOW - Statement of Work 

SRM&QA - Safety, Reliability, Maintainability, and Quality 
Assurance 

SSE - Software Support Environment of the Space Station Freedom 
Program 

SSFP - Space Station Freedom Program 
STD - Standard 

TBD - To be determined (at a later date) 

TMIS - Technical and Management Information System of the Space 
Station Freedom Program 

TRR - Test Readiness Review 

V&V “ Verification & Validation. 

WBS - Work Breakdown Structure 
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9 . 0 GLOSSARY 

For terms not appearing in this glossary, refer to the IEEE Stan- 
dard Glossary (as referenced in Section 2.2). 


Acceptance Review - The phase transition review for the Acceptance 
and Delivery life-cycle phase. 

Acquirer - An organization that acquires a capability, such 
as an information system. 

Adaptation - The tailoring of the life-cycle and documentation 

standards (within the specifications of the rules and guide- 
lines) for a specific program/project, information system, 
or component. 

Allocation - The process of apportioning requirements at one level 
in the decomposition tree to the subsystems or subcomponents 
at the next lower level in the decomposition. 

Assembly - A physical element of a hardware component consisting 
of one or more line replaceable units. A hardware component 
is composed of one or more physical assemblies. 

Assurance - Includes any and all activities, independent of 
organization conducting the activity, that demonstrate 
the conformance of a product to a prespecified criteria 
(such as to a design or to a standard) . 

Assurance Specification - One of the four documents in the docu- 
mentation set for an information system or component? it en- 
compasses all the technical (i.e., non-planning) aspects of 
the assurance activities for an information system or compo- 
nent. 

Baselining - The official acceptance of a product or its 

placement under configuration management as defined in the 
management plan. 

Code Q - (NASA) Office of Safety, Reliability, Maintainability, 
and Quality Assurance 

Component - 1) One of the three parts making up an information 
system: software, hardware, or operational procedures. 

2) A portion of a higher-level component of the same type? 
e.g., a component of the software component (of an information 
system) . 

Critical Design Review - The phase transition review for the 
Detailed Design life-cycle phase. 
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Data Item Description - The table of contents and associated 
content description of a document or volume. 

Design Element - An identifiable part of a component's archi- 
tectural design. 

Developer - The provider organization responsible for development 
of an information system or of a hardware, software, or 
operational procedures component. 

Document - One of the four basic types of information for each 
information system or component: 1) Management Plan, 

2) Product Specification, 3) Assurance Specification, and 
4) Management Control and Status Reports Document. A 
document consists of one or more volumes. 

Documentation Set - The four basic documents for each information 
system or component thereof. 

Evolutionary Acquisition - The acquisition of an information system 
over a relatively long period of time in which two or 
more complete iterations of the life-cycle will be employed 
to revise and extend the system to such an extent as to 
require a major requirements analysis and therefore subse- 
quent life-cycle iterations. 

Increment - A pre-defined set of units integrated for integration 
testing by the development organization in response to incre- 
mental development plans. 

Incremental Development - The process of developing a product 
before delivery in a series of segments. These segments 
remain internal to the development organization. The process 
is used to avoid the big bang approach to software development 
and help minimize risk. The segments are defined based on 
the design and documented in the design section of the product 
specification. The process leads to a single delivery unless 
used in conjunction with "phased delivery." 

Independent Verification and Validation - Verification and 

validation performed by an independent organization. In 
general, this is intended to be independent of the develop- 
ment organization. For complete independence, the IV&V 
organization must report directly to or be funded directly 
by the acquirer. 

Information System - 1) Any system composed of hardware, soft- 
ware, and operational procedures components required to 
process, store, and/or transmit data. 2) An integrated 
combination of software, hardware, and operational pro- 
cedures components that provides a useful capability. An 
information system is generally software- intensive. 
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Inheritables - Existing software or hardware to be drawn upon in 
developing a new information system. The inheritables may 
be modified to meet the new system's requirements. 

Instantiate - 1. To represent an abstraction by a concrete 
instance (e.g., heroes instantiate ideals). 2. within 
Ada, the process of creating an instance of a generic 
subprogram or package. 

Line Replaceable Unit - A hardware unit that is part of 

blv that is defined to be the lowest replaceable element of 
a hardware component. An assembly is composed of one or more 

LRUs. 

Management Control and Status Reports Document - One of the 

documents in the documentation set for an information system 
or component? it represents a "logical” home for all report 
and request forms. 

Management Plan - One of the four documentation set documents; 

it encompasses all planning information for an infomation 
system or component, including management, engineering, and 
assurance planning. 

Partitioning - The process of determining the content for each 
delivery when using the phased delivery approach, or for 
determining the content of each segment when using incre- 
mental development. 

Phase (of a life-cycle) - A set of activities and associated 

products and reviews that make up one step of a multi-step 
process for developing systems and their component. An 
information system life-cycle has seven standard phases: 

1) Concept and Initiation? 2) Requirements? 3) Design? 

4) Implementation Coordination (or Implementation or 
Fabrication) ? 5) Integration and Test? 6) Acceptance Test, 
and 7) Sustaining Engineering and Operations. In some cases, 
phase 3 contains multiple levels of design, such as archi- 
tectural and detailed. 

Phase Transition Review - The review at the end of a phase trig- 
gering transition to the next phase. 

Phased Delivery - The process of developing and delivering a 

product in stages, each providing an increasing capability 
for an information system or component. The process may pe 
employed to provide an early operational capability to users, 
for budgetary reasons, or because of risk, size, or complex- 
ity. Each delivery must undergo acceptance testing prior to 
release for operational use. The capabilities provided in 
each delivery are determined by prioritizing and partitioning 
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the requirements. This must be documented in the require- 
ments section of the product specification. 

Preliminary Design Review - The phase transition review for the 
Architectural Design life-cycle phase. 

Product Specification - One of the four documentation set 

documents for an information system or component; it encom- 
passes all the engineering and technical support information 
related to the development of an information system or 
component. 

Prototyping - A process used to explore alternatives and minimize 
risks. Prototyping can be used in any life-cycle phase. 

The product of the process is a report. By-products (such 
as software, hardware, and models) of the process can be 
preserved for subsequent use. 

Provider - An organization providing a capability to an acquirer? 
e.g., the developer or an organization providing independent 
verification and validation. 

Quality Assurance - A subset of the total assurance activities 
generally focused on conformance to standards and plans. 

In general, these assurance activities are conducted by 
the SRM&QA organization. 

Quality Engineering - The process of incorporating reliability, 
maintainability, and other quality factors into system, 
hardware, software, and operational procedures products. 

Repository - A collection of standards, procedures, guides, 

practices, rules, etc. that supplements information con- 
tained in the documentation set for an information system 
or component - In general, the documentation set describes 
"what" is to be done and the repository provides the "how- 
to” instructions. A repository usually contains information 
that is applicable to multiple information systems and com- 
ponents . 

Requirements Allocation - The process of distributing requirements 
of an information system or component to subordinate in- 
formation systems (subsystems) or components. 

Requirements Partitioning - The process of distributing require- 
ments of an information system or component to different 
deliveries in support of phased delivery. 

Requirements Review - The phase transition review for the Require- 
ments life-cycle phase. 
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Review Item Discrepancy - A type of discrepancy report used when 
reviewing documentation. 

Risk - The combined effect of the likelihood of an unfavorable 
occurrence and the potential impact of that occurrence. 

Risk Management - The process of assessing potential risks and 
reducing those risks within dollar, schedule, and other 
constraints. 

Roll-out - A mechanism for recording sections of a document in 
physically separate volumes while maintaining traceability 
and links. When using roll-out, a volume is subordinate 
to a parent document or volume. 

Software Management and Assurance Program - Sponsored by NASA 
Code Q to foster more effective and productive software 
engineering methodologies. 

Subsystem - In the information system decomposition context, a 
subsystem is an information system that is subordinate to 
a higher level information system and is parent to soft- 
ware, hardware, and operational procedures components, or to 
other (lower level) information systems. 

Template - Within these Standards, a template is a DID frame- 
work used in the roll-out process for defining the specific 
format of a section rolled-out into a physically separate 
volume . 

Test Readiness Review - The phase transition review for the 
Integration and Testing life-cycle phase. 

Testing - The process of exercising or evaluating an information 
system or component by manual or automated means to demon- 
strate that it satisfies specified requirements or to iden- 
tify differences between expected and actual results. 

Tool - A hardware device or computer program used to help develop, 
test, analyze, or maintain another device or computer program 
or its documentation. (IEEE Std 729-1983) 

Unit - An identifiable part of a detailed design. A level of 
decomposition for the purpose of physical design and im- 
plementation for a software or hardware component. 

Validation - 1) Assurance activities conducted to determine that * 
the requirements for a product are correct; i.e. to build the 
right product. 2) (IEEE Std 729-1983) The process of evalu- 
ating software at the end of the software development process 
to ensure compliance with software requirements. 
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Verification - 1) Assurance activities conducted to determine that 
a product is being built correctly in accordance with design 
and requirements specifications; i.e., to build the product 
right. 2) (IEEE Std 729-1983) "The process of determining 
whether or not the products of a given phase of ... develop- 
ment . . . fulfill the requirements established during the 
previous phase." 

Volume - A physically separate section of one of the four docu- 
ments in a documentation set. 


10.0 NOTES 
None. 
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11.0 APPENDICES 


APPENDIX A 
INFORMATION SYSTEM 

PRODUCT SPECIFICATION DOCUMENT SAMPLE OUTLINE 


EXPLANATORY NOTE 

The purpose of a product specification for an information 
system is to document all the technical aspects relative to 
development of the information system throughout its 
life-cycle. 

This sample outline contains the complete substructure of 
all the Section 7 DIDs "rolled-up” into a single volume 
product specification. All levels of substructure may not 
be required for a single-volume product specification. 

A section of a product specification may be rolled-out, 
using the Product Specification Template (SMAP-DID-P999) 
and associated rules, into a separate volume as necessary 
for such reasons as assignment of the tasks generating the 
information in that section to a separate organization, 
documentation size and complexity, ease of configuration 
control, or phase of the life-cycle in which the 
information is generated. 


TABLE OF CONTENTS 


Section 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 
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3 . 0 CONCEPT 

3.1 

3.1.1 

3.1.2 

3.1.3 

3.1.4 

3.2 

3.3 

3.4 

4 . 0 REQUIREMENTS 

4 . 1 Requirements Approach and Tradeoffs 

4.2 External Interface Requirements 

4.2.1 Interfaces 

4.3 Requirements Specification 

4.3.1 Process and Data Requirements 

4.3.2 Performance and Quality Engineering Requirements 

4.3.3 Safety Requirements 

4.3.4 Security and Privacy Requirements 

4.3.5 Implementation Constraints 

4.3.6 Site Adaptation 

4.3.7 Design Goals 

4.4 Traceability to Parent’s Design 

4.5 Partitioning for Phased Delivery 

5 . 0 DESIGN 

5.1 Design Approach and Tradeoffs 

5.2 External Interfaces Design 

5.2.1 User Interfaces Design 

5.2.2 Interface Allocation 

5 . 3 Architectural Design 

5.4 Requirements Allocation and Traceability 

5.5 Partitioning for Incremental Development 

6 . 0 VERSION DESCRIPTION 

6.1 

6.2 
6 . 2.1 
6 . 2.2 
6.3 

6.3.1 

6.3.2 

6.3.3 


Product Description 
Inventory and Product 
Materials Released 
Product Content 
Change Status 

Installed Changes 
Waivers 

Possible Problems and Known Errors 


Definition of Information System 
Purpose and Scope 
Goals and Objectives 
Description 
Policies 
User Definition 

Capabilities and Characteristics 
Sample Operational Scenarios 
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7.0 

7.1 

7.1. ] 

7.1. : 

7.1. ] 

7.1. ' 

7.1. ! 

7.1. < 

7.2 

7.3 

8.0 

8.1 

8.2 

9.0 

10.0 
11.0 
12.0 


USER AND OPERATOR DOCUMENTATION 
User 1 s Guide 

Overview of Purpose and Function 
Installation and Initialization 
Startup and Termination 
Functions and their Operation 
Error and Warning Messages 
Recovery Steps 
User's Training Materials 
Operator's Training Materials 

MAINTENANCE MANUAL 

Problem Detection and Fault Isolation 
Preventative Maintenance 

ABBREVIATIONS AND ACRONYMS 

GLOSSARY 

NOTES 

APPENDICES 
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APPENDIX B 
HARDWARE COMPONENT 

PRODUCT SPECIFICATION DOCUMENT SAMPLE OUTLINE 


EXPLANATORY NOTE 

The purpose of a hardware component product specification 
is to document all the technical aspects relative to the 
development of this component of an information system 
throughout its life-cycle. 

This sample outline contains the complete substructure of 
all the Section 7 DIDs "rolled-up” into a single volume 
product specification. All levels of substructure may not 
be required for a single— volume product specification. 

A section of a product specification may be rolled-out, 
using the Product Specification Template ( SMAP-DID-P9 9 9 ) 
and associated rules, into a separate volume as necessary 
for such reasons as assignment of the tasks generating the 
information in that section to a separate organization, 
documentation size and complexity, ease of configuration 
control, or phase of the life-cycle in which the 
information is generated. 


TABLE OF CONTENTS 


Section 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 

3 . 0 CONCEPT 

3.1 Definition of Hardware 

3.1.1 Purpose and Scope 

3.1.2 Goals and Objectives 
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3.1.3 

3.1.4 

3.2 

3.3 

3.4 

4.0 

4.1 

4.2 

4.2.1 

4.3 

4.3.1 

4.3.2 

4.3.3 

4.3.4 

4.3.5 

4.3.6 

4.3.7 

4.4 

4.5 

5.0 

5.1 

5.1.1 

5.1.2 

5.1.3 
5.1.3 

5.1.3 

5.1.4 

5.1.5 
5.2 

5.2.1 

5.2.2 
5.2.2 

5.2.2 

5.2.3 
5.2.3 

5.2.3 

5.2.4 

6.0 

6.1 

6.2 

6 . 2 . 

6 . 2 . 

6.3 

6.3. 

6.3. 
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Description 
Policies 
User Definition 

Capabilities and Characteristics 
Sample Operational Scenarios 

REQUIREMENTS 

Requirements Approach and Tradeoffs 
External Interface Requirements 
Interfaces 

Requirements Specification 
Process Requirements 

Performance and Quality Engineering Requirements 

Safety Requirements 

Security and Privacy Requirements 

Implementation Constraints 

Site Adaptation 

Design Goals 

Traceability to Parent’s Design 
Partitioning for Phased Delivery 

DESIGN 

Architectural Design 

Design Approach and Tradeoffs 
Architectural Design Description 
External Interface Design 
. l Interface Design 

. 2 Interface Allocation 

Requirements Allocation and Traceability 
Partitioning for Incremental Development 
Detailed Design 

Detailed Design Approach and Tradeoffs 
Detailed Design Description 

.1 Assembly Design and Traceability to Architectural 

Design 

.2 Detailed Design of Assemblies 

External Interface Detailed Design 
.1 Interface Allocation Design 

.2 Physical Interface Design 

Fabrication Notes 

VERSION DESCRIPTION 

Product Description 
Inventory and Product 
Materials Released 
Product Content 
Change Status 

Installed Changes 
Waivers 
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6.3.3 Possible Problems and Known Errors 

7 . 0 USER DOCUMENTATION 

7 . 1 User * s Guide 

7.1.1 Overview of Purpose and Function 

7.1.2 Installation and Initialization 

7.1.3 Startup and Termination 

7.1.4 Functions and their Operation 

7.1.5 Error and Warning Messages 

7.1.6 Recovery Steps 

7.2 User*s Training Materials 

8.0 MAINTENANCE MANUAL 

8 . 1 Problem Detection and Fault Isolation 

8.2 Preventative Maintenance 

9.0 ABBREVIATIONS AND ACRONYMS 

10.0 GLOSSARY 

11.0 NOTES 

12.0 APPENDICES 
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APPENDIX C 
SOFTWARE COMPONENT 

PRODUCT SPECIFICATION DOCUMENT SAMPLE OUTLINE 


EXPLANATORY NOTE 

The purpose of a software component product specification 
is to document all the technical aspects relative to the 
development of this component of an information system 
throughout its life-cycle. 

This sample outline contains the complete substructure of 
all the Section 7 DIDs "rolled-up” into a single volume 
product specification. All levels of substructure may not 
be required for a single-volume product specification. 

A section of a product specification may be rolled-out, 
using the Product Specification Template (SMAP-DID-P999) 
and associated rules, into a separate volume as necessary 
for such reasons as assignment of the tasks generating the 
information in that section to a separate organization, 
documentation size and complexity, ease of configuration 
control, or phase of the life-cycle in which the 
information is generated. 


TABLE OF CONTENTS 


Section 

1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 

3 . 0 CONCEPT 

3.1 Definition of Software 

3.1.1 Purpose and Scope 

3.1.2 Goals and Objectives 
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3.1.3 Description 

3.1.4 Policies 

3.2 User Definition 

3.3 Capabilities and Characteristics 

3.4 Sample Operational Scenarios 


4 . 0 REQUIREMENTS 


4.1 

4.2 

4.2.1 

4.3 

4.3.1 

4.3.2 

4.3.3 

4.3.4 

4.3.5 

4.3.6 

4.3.7 

4.4 

4.5 


Requirements Approach and Tradeoffs 
External Interface Requirements 
Interfaces 

Requirements Specification 

Process and Data Requirements 

Performance and Quality Engineering Requirements 

Safety Requirements 

Security and Privacy Requirements 

Implementation Constraints 

Site Adaptation 

Design Goals 

Traceability to Parent* s Design 
Partitioning for Phased Delivery 


5.0 DESIGN 


5.1 

5.1.1 

5.1.2 

5.1.3 

5. 1.3.1 

5. 1.3. 2 

5.1.4 

5.1.5 

5.2 

5.2.1 

5.2.2 

5. 2. 2.1 

5. 2. 2. 2 

5.2.3 

5. 2. 3.1 

5. 2. 3. 2 

5.2.4 

5.2.5 

5. 2. 5.1 

5.2. 5. 1.1 

5. 2. 5. 1.2 

5. 2. 5. 1.3 
5. 2. 5. 2 

5. 2. 5. 2.1 

5. 2. 5. 2. 2 

5. 2. 5. 2.3 

5 . 2 . 5 . 3 


Architectural Design 

Design Approach and Tradeoffs 
Architectural Design Description 
External Interface Design 
Interface Design 
Interface Allocation 

Requirements Allocation and Traceability 
Partitioning for Incremental Development 
Detailed Design 

Detailed Design Approach and Tradeoffs 
Detailed Design Description 
Compilation Unit 

Detailed Design of Compilation Units 
External Interface Detailed Design 
Interface Allocation Design 
Physical Interface Design 
Coding and Implementation Notes 
Firmware Support Manual 
Devices 

Physical Description 
Installation and Replacement 
Limitations 
Programming Tools 
Equipment 
Software 

Programming Procedures 
Security Implications 
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6 . 0 VERSION DESCRIPTION 

6.1 
6.2 
6 . 2.1 
6 . 2.2 
6.3 

6.3.1 

6.3.2 

6.3.3 

7 . 0 USER DOCUMENTATION 

7.1 

7.1.1 

7.1.2 

7.1.3 

7.1.4 

7.1.5 

7.1.6 
7.2 

8 . 0 MAINTENANCE MANUAL 

8 . 1 Implementation Details 

8.2 Modification Aids 

8 . 3 Code Adaptation 

9.0 ABBREVIATIONS AND ACRONYMS 

10.0 GLOSSARY 

11.0 NOTES 

12 . 0 APPENDICES 


User's Guide 

Overview of Purpose and Function 
Installation and Initialization 
Startup and Termination 
Functions and their Operation 
Error and Warning Messages 
Recovery Steps 
User's Training Materials 


Product Description 
Inventory and Product 
Materials Released 
Product Content 
Change Status 

Installed Changes 
Waivers 

Possible Problems and Known Errors 
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APPENDIX D 

OPERATIONAL PROCEDURES COMPONENT 
PRODUCT SPECIFICATION DOCUMENT SAMPLE OUTLINE 


EXPLANATORY NOTE 

The purpose of an operational procedures component product 
specification is to document all the technical aspects 
relative to the development of this component of an 
information system throughout its life-cycle. 

This sample outline contains the complete substructure of 
all the Section 7 DIDs "rolled-up” into a single volume 
product specification. All levels of substructure may not 
be required for a single-volume product specification. 
Usually, the operational procedures manual (section 6.2.2 
here) is rolled-out into a physically separate volume. 

A section of a product specification may be rolled-out, 
using the Product Specification Template (SMAP-DID-P999) 
and associated rules, into a separate volume as necessary 
for such reasons as assignment of the tasks generating the 
information in that section to a separate organization, 
documentation size and complexity, ease of configuration 
control, or phase of the life-cycle in which the 
information is generated. 


TABLE OF CONTENTS 


Section 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2 . 2 Applicable Documents 

2 . 3 Information Documents 
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3 . 0 CONCEPT 


3.1 Definition of Operational Procedures 

3.1.1 Purpose and Scope 

3.1.2 Goals and Objectives 

3.1.3 Description 

3.1.4 Policies 

3.2 User Definition 

3.3 Capabilities and Characteristics 

3.4 Sample Operational Scenarios 

4 . 0 REQUIREMENTS 

4.1 Requirements Approach and Tradeoffs 

4.2 External Interface Requirements 

4.2.1 Interfaces 

4.3 Operational Procedures Requirements 

4.3.1 Process Requirements 

4.3.2 Safety Requirements 

4.3.3 Security and Privacy Requirements 

4.3.4 Implementation Constraints 

4.3.5 Design Goals 

4.4 Traceability to Parent's Design 

4.5 Partitioning for Phased Delivery 


5 . 0 DESIGN 

5.1 Design Approach and Tradeoffs 

5 . 2 Design Description 

5.3 External Interface Design 

5.4 Requirements Traceability 

5.5 Partitioning for Incremental Development 


6 . 0 VERSION DESCRIPTION 


6.1 
6.2 
6 . 2.1 
6 . 2.2 
6 . 2 . 2.1 
6 . 2 . 2 . 2 

6 . 2 . 2. 3 

6 . 2 . 2. 4 
6.3 

6.3.1 

6.3.2 

6.3.3 


Product Description 
Inventory and Product 
Materials Released 

Operational Procedures Manual (usually rolled-out) 
System Preparation and Set-Up Procedures 
Standard Operating Procedures 
Fault and Recovery Procedures 
Emergency Procedures 
Change Status 

Installed Changes 
Waivers 

Possible Problems and Known Errors 
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7.0 USER AND OPERATOR DOCUMENTATION 

7.1 

7.1.1 

7.1.2 

7.1.3 

7.1.4 

7.1.5 

7.1.6 

7.2 

7.3 

8.0 ABBREVIATIONS AND ACRONYMS 

9 . 0 GLOSSARY 

10.0 NOTES 

11.0 APPENDICES 


User's Guide 

Overview of Purpose and Function 
Installation and Initialization 
Startup and Termination 
Functions and their Operation 
Error and Warning Messages 
Recovery Steps 
User's Training Materials 
Operator's Training Materials 
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APPENDIX E 

STANDARDS AND GUIDELINES 
PRODUCT SPECIFICATION DOCUMENT SAMPLE OUTLINE 


EXPLANATORY NOTE 

The purpose of a standards and guidelines product 
specification is to document all the technical aspects 
relative to the development of a new standard including the 
documenting of the standard itself. 

This sample outline contains the complete substructure of 
all the Section 7 DIDs "rolled-up" into a single volume 
product specification. All levels of substructure may not 
be required for a single-volume product specification. 
Usually, the standards and associated guidelines (section 

6.2.2 here) are rolled-out into a physically separate 
volume . 

A section of a product specification may be rolled-out, 
using the Product Specification Template (SMAP-DID-M999 ) 
and associated rules, into a separate volume as necessary 
for such reasons as assignment of the tasks generating the 
information in that section to a separate organization, 
documentation size and complexity, ease of configuration 
control, or phase of the life-cycle in which the 
information is generated. 


TABLE OF CONTENTS 


Section 


1.0 INTRODUCTION 

1.1 Identification of Volume 

1.2 Scope of Volume 

1.3 Purpose and Objectives of Volume 

1.4 Volume Status and Schedule 

1.5 Volume Organization and Roll-Out 

2 . 0 RELATED DOCUMENTATION 

2 . 1 Parent Documents 

2.2 Applicable Documents 

2 . 3 Information Documents 


174 


Release 4.3, 2/28/89 



PRODUCT SPECIFICATION DOCUMENTATION STANDARD 
STANDARDS AND GUIDELINES PRODUCT SPECIFICATION SAMPLE OUTLINE 


3 . 0 CONCEPT 

Definition of Standards 
Purpos4 and Scope 
Goals and Objectives 
Description 
Policies 
User Definition 

Capabilities and Characteristics 
Sample Operational Scenarios 

4 . 0 REQUIREMENTS 

Requirements Approach and Tradeoffs 
External Interface Requirements 
Interfaces 

Standards Requirements 

Process and Quality Engineering Requirements 
Safety Requirements 
Security and Privacy Requirements 
Implementation Constraints 
Design Goals 

Traceability to Parent's Design 
Partitioning for Phased Delivery 

5 . 0 DESIGN 

5.1 Design Approach and Tradeoffs 

5 . 2 Design Description 

5.3 External Interface Design 

5.4 Requirements Traceability 

5.5 Partitioning for Incremental Development 

6 . 0 VERSION DESCRIPTION 

6 . 1 Product Description 

6.2 Inventory and Product 

6.2.1 Materials Released 

6.2.2 The Standard 

6. 2. 2.1 Overview of Standard 

6. 2. 2. 1.1 Scope of Standard 

6. 2. 2. 1.2 Rationale for Standard 

6. 2. 2. 1.3 Interface with Other Standards 

6 . 2 . 2 . 2 <The Standard> 

6.2.2. 3 Application and Support of <the Standard> 

6. 2. 2. 3.1 Guidelines for Use of <the Standard> 

6. 2. 2. 3. 2 Tools Supporting the Application and Use of <the “ 

Standard> 

6. 2. 2. 4 Assurance and Enforcement of <the Standard> 
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6 . 3 Change Status 

6.3.1 Installed Changes 

6.3.2 Waivers 

6.3.3 Possible Problems and Known Errors 

7 . 0 USER DOCUMENTATION 

7 . 1 User • s Guide 

7.2 User's Training Materials 

8 . 0 MAINTENANCE MANUAL 

9.0 ABBREVIATIONS AND ACRONYMS 


10.0 GLOSSARY 


11.0 NOTES 


12 . 0 APPENDICES 
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